Microsoft-ui-xaml: 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.

[chingucoding]

I would like to tackle this issue :)

CC @ranjeshj @jevansaks

[chingucoding]

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.

[chingucoding]

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.

[chingucoding]

There are pro's and con's to that reasoning. On the one hand, yes developers always align with the system when we say "Auto will always be the default, but what Auto will actually be may change".

But what happens if we change what Auto maps to? Then, apps behaviors may become more inconsistent as the TabView has changed without the app being updated for that accordingly i.e. that there may be visual inconsistencies.

Having this "System default that might change" is not my favorite option. If devs want the default option, why not make it the initial value, instead of having a sort of wrapper for the current default.

[stmoy]

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)

In general, my philosophy is: do what WCT does (unless what WCT is bad).

WCT behavior in this case seems to be agnostic to the Icon/Content - meaning the Tab always has a fixed width for both the unselected and selected state. This results in the behavior of the Text showing when the tab is unselected, which I don't think is a great look.

The following markup produces the following visuals:

      <controls:TabViewItem Header="Home" Icon="Home">
        <TextBlock Padding="16">The TabView control has multiple uses.</TextBlock>
      </controls:TabViewItem>
      <controls:TabViewItem Header="Tab 3">
        <TextBlock Padding="16">You can enable drag-and-drop and reorder the tabs too.</TextBlock>
      </controls:TabViewItem>
      <controls:TabViewItem Header=" ">
        <TextBlock Padding="16">You can enable drag-and-drop and reorder the tabs too.</TextBlock>
      </controls:TabViewItem>

Tab 1 Selected

Tab 2 Selected

Tab 3 Selected

My preferred behavior would be that tabs without icons would show blank regardless of if their text is set.

Thoughts?

How should the "Auto" CloseButtonOverlayMode work?

The platform uses Auto as the default enum value in several situations, including places where the developer expects some automatic behavior (like TeachingTipPlacement) or places where the mode describes a visual layout that might change later. Basically all of the enums that describe UI and end in *Mode have an Auto value as their default. (CoreDragUIContentMode,ElementSoundMode,NavigationViewPanDisplayMode,TeachingTipPlacementMode,etc.)

To that end, since there is already the Persistent behavior, I think the introduction of Auto makes sense.

If devs want the default option, why not make it the initial value, instead of having a sort of wrapper for the current default.

Semantically, I think Auto actually means "I don't have an opinion, let the platform decide for me" and not "I specifically like the default value". Auto represents the platform default, meaning that apps that don't have an opinion will have consistent behavior with other apps by default even if the default changes. The alternate without Auto is that if the default changes, every app will need to update their default in order to remain consistent with the system.

CC: @MikeHillberg

[chingucoding]

My preferred behavior would be that tabs without icons would show blank regardless of if their text is set.

Thoughts?

Yes that seems to be the best way in my opinion. Showing 3 letters of the TabItem header usually isn't really helpful, so I think this is the best way to handle missing icons.

Semantically, I think Auto actually means "I don't have an opinion, let the platform decide for me" and not "I specifically like the default value". Auto represents the platform default, meaning that apps that don't have an opinion will have consistent behavior with other apps by default even if the default changes. The alternate without Auto is that if the default changes, every app will need to update their default in order to remain consistent with the system.

Oh, I see. I have updated the PR accordingly so that Auto behaves the same as Persistent .

[ZhaoMJ]

Could it be possible to have an option making the same style and looking as WCT TabView? WCT TabView is gonna be deprecated but I really miss its reveal and acrylic effects, which, in my opinion, still looks more consistent with the current Fluent Design system. I also know some developers want to style their TabView in that way, so it would be great to provide an option such that they can update from WCT without re-designing their apps. Furthermore, I'm also wondering in the future of WinUI3, as everything will be united, in addition to matching the chromium Edge from WinUI side, can Edge also steps towards the current fluent design? It would be great to see Edge uses TabView and other WinUI components and becomes more "fluent" :)

[shaheedmalik]

If the WCT version has fluent, then the WinUI TabView needs fluent in order to obtain parity.