Proposal: TabView Parity with WCT TabView

[stmoy]

Proposal: TabView Parity with WCT TabView

Summary

The WinUI TabView is missing two main features relative to the Windows Community Toolkit TabView:

Tab Width Behavior: Compact API Link

The unselected tabs show only their icon and no text until they are selected.

Overlay Close Button API Link

The x-to-close button is shown when the user hovers over the tab.

Rationale

• The WinUI TabView is so close to being feature complete relative to the Windows Community Toolkit TabView. Once WinUI TabView is at parity, we can deprecate the WCT TabView.

Scope

Capability	Priority
Tab Width Behavior: Compact	Must
Overlay Close Button	Must

Important Notes

The proposed API for these properties is outlined in #304, which is the initial proposal for TabView.

Specifically, the following APIs are proposed:

Tab Width Behavior: Compact

Existing enum (with new value) and existing property

TabWidthMode : {Equal, SizeToContent, Compact}

<TabView TabWidthMode="Compact" />

Overlay Close Button

New enum and property

CloseButtonOverlay : {Auto, OnHover, Persistent}

<TabView CloseButtonOverlay="OnHover" />

Open Questions

[mdtauk]

Can we get Tab Placement for sides and bottom at some point too?

[stmoy]

This issue is specifically about getting to parity with the Windows Community Toolkit version. We'd like to have alternate Tab Placement modes, but those features are tracked in #1332.

[marcelwgn]

I would like to tackle this issue :)

CC @ranjeshj @jevansaks

[marcelwgn]

I have already finished most features of this proposal, however there are a few questions that came up during development:

1. How should we handle "Compact" mode with tab items that have no icon? Should we show nothing (which looks a bit confusing in my opinion)
2. How should the "Auto" CloseButtonOverlayMode work?

Current status:

[Felix-Dev]

@chingucoding Based on the spec review for TabView:

CloseButtonOverlayMode

Describes the behavior of the close button of unselected tabs. Values are {Auto, OnHover, Persistent}. Default is Auto. In WinUI 2.2, Auto maps to Persistent.

@stmoy can say if anything has changed since then (I'm not aware of a spec change). Should be fine going ahead and treat Auto as mapping to Persistent as called out in the spec review.

How should we handle "Compact" mode with tab items that have no icon? Should we show nothing (which looks a bit confusing in my opinion)

Yes, that's my suggestion. This already is the case if we don't specify an icon and header for the default tab with mode anyway, see below:

This should be applied to the compact mode too. If no icon is specified then we show nothing. This is consistent with the current behavior shown above. It's up to the developer of the app to make sure the user can meaningfully differentiate tabs from one another.

[marcelwgn]

If Auto should behave like Persistent is there any reason to have that option at all?
Having multiple options that are equivalent creates unnecessary confusion in my opinion.

[Felix-Dev]

@chingucoding Reading further through the spec review of TabView V1, it seems there is still room for discussion about this setting in a future TabView V2 spec. The default value itself (currently Persistent) might be up to a change (as indicated by In WinUI 2.2...). Based on this thinking, using Auto in your UI would always give you the current default button overlay mode if your app's TabView should follow the default system UI. That said...the default value shouldn't be changed back and forth multiple times over the lifetime of WinUI and its TabView control. If it does change, however, you are covered.