The WinUI Team has opened a spec and PR for this feature.

Proposal: Tabs Control

Summary

The Tab control is a way to display a set of tabs and their respective content. Tab controls are useful for displaying several pages (or documents) of content while giving a user the capability to rearrange, open, or close new tabs.

Rationale

As a UI paradigm, Tabs has been around for a long time, and can be found in everything from dialogs to browsers. The focus for this proposal is "document-style" tabs, which enables a user to rearrange, open, and close new tabs.

Tabs in the Edge browser

Tabs in Visual Studio

Note that "static-style" tabs also exist as a paradigm. "Static-style" tabs are tabs that do not support user interaction beyond switching tabs. UWP already has a solution for static-style tabs in the form of Pivot and NavigationView.

Static-style tabs in WPF

A lack of a proper Tab control has been a continual painpoint in UWP, particularly for developers attempting to migrate from WPF.

The XAML platform provides a number of ways to achieve "static-style" tabs in Pivot and top NavigationView. However, these solutions do not well support "document-style" tabs which support user reorder, opening, and closing tabs. The platform does demonstrate how to create "document-style" tabs in the Van Arsdel sample using top NavigationView:

Although these workarounds have unblocked apps trying to create "document-style" tabs, they have a number of limitations, including:

• Significant effort up to (and including) retemplating to build simple tabs
• No built-in support for closing tabs
• No built-in support for drag/drop into new windows
• No built-in support for moving a tab from a window and combining it with another window
• Limited keyboard and accessibility support

Fortunately, the Windows Community Toolkit has created a TabView control that helps address some of the aforementioned pain points.

However, the Windows Community Toolkit is a managed/C# project, meaning that customers that don't want to load the CLR or are particularly performance-focused cannot leverage the Windows Community Toolkit implementation.

The goal for this feature proposal is not to "reinvent the wheel" - instead, we hope to take the learnings from the WCT implementation and discussion and build a native control directly into WinUI.

Functional Requirements

Important Notes

To replicate the behavior of Microsoft Edge:

<TabControl TabWidthBehavior="Equal"
            CanCloseTabs="True"
            CloseButtonOverlay="OnHover"
            CanDragItems="True"
            CanReorderItems="True"
            TabDraggedOutside="OpenTabInNewWindow">
    <TabControl.TabFooter>
        <Button Content="+" Click="NewTab_Click" />
    </TabControl.TabFooter>
    ...
</TabControl>

The TabControl also supports databinding:

<TabControl ItemsSource="{x:Bind TabItemCollection}" />

TabControl properties and events

TabItem properties and events

Open Questions

1. Should Tab Tearoff be something that the control handles or that the app handles?
The app will handle it. We will have good samples showing how.

2. Should there be a built-in "Add new tab" button? (I suspect probably not, because the control doesn't own the collection of Tabs.)
The app will own the "Add tab" button. In the case of Terminal, for example, they will add a button with a dropdown. Adding an "Add" button doesn't add much value.

3. Should TabItem.Icon be IconElement or IconElementSource?
IconElement. IconElementSource is useful when the same icon could appear in multiple places in the tree, which isn't the case here.

4. How can an app customize that the Selected tab looks like (ie. in Edge)?

5. The API currently takes a lot of inspiration from the Toolkit. Are there any chances to iterate/improve?

Release Checklists

Prerelease readiness

• Dev: quality review + code review done
• Dev: test coverage added
• Dev: initial accessibility review done
• Dev: telemetry implemented
• PM: spec up to date
• PM: feature ready for feedback
• PM: docs.microsoft.com updates ready

Stable release readiness

• Dev: feature previously shipped in a prerelease NuGet package
• Dev: Azure CI tests passing
• Dev: accessibility review done
• Dev: API review done
• Dev: IDL attribute switched from preview to public
• Dev: Add test coverage to the NugetReleaseTest test
• PM: spec done
• PM: glob/loc, privacy, security, license compliance ready
• PM: customer validation done
• PM: docs.microsoft.com updated
• PM: Xaml Controls Gallery updated