Microsoft-ui-xaml: Proposal: Ability to add Content Below the Tab strip but not part of the Tab Item's content like in Browsers

[MarkIvanDev]

Proposal: Ability to add Content Below the Tab strip but not part of the Tab Item's content like in Browsers

Summary

Add a way to add content below the Tab strip that is still a part of the TabView control like how most Browsers implement their tabs (e.g. Favorites bar, Navigation commands and URL bar).

Rationale

• There is almost always a need to show common UI that can be shared by all the tabs in a TabView that cannot be satisfied by the Header and Footer placements.
• All Browsers (imho, browsers are great examples of how tabbed UI can be used) have this when using a Tabbed UI

Scope

| Capability | Priority |
| :---------- | :------- |
| Add common content below the Tab strip for all the Tab items | Must |
| This content will be collapsed if not set | Must |

Important Notes

New properties, TabStripContent and TabStripContentTemplate, can be added to TabView.

And add a ContentPresenter that will span the whole second row of TabContainerGrid
https://github.com/microsoft/microsoft-ui-xaml/blob/c5fa8a6b45efe820b80aa994751801df553117f7/dev/TabView/TabView.xaml#L29

<ContentPresenter Grid.Row="1"
                                Grid.ColumnSpan="4"
                                HorizontalAlignment="Stretch"
                                Content="{TemplateBinding TabStripContent}"
                                ContentTemplate="{TemplateBinding TabStripContentTemplate}"/>

Open Questions

[stmoy]

@MarkIvanDev - great idea! I will pitch this internally to the team.

[MarkIvanDev]

That is great to know. I hope this feature will push through.

[stmoy]

Hi @MarkIvanDev - I pitched this to the team and we agreed that it sounds like a good (and conceptually straightforward) idea! However, we expect that there would be a non-zero amount of design work required. Some of the questions that came up were:

• How would the visual design of this feature work with the existing TabView (where the selected tab's background seamlessly blends into the page background)?
• Would it be beneficial to separate the TabStrip component out of the TabView entirely and make it its own usable widget?
• Are there specific customers that would use this feature, or is this more of a "nice to have"?

For that last question in particular, I could use your help! @MarkIvanDev, if we built this feature, are you working on an app that would use it? If so, can you give more info about that app?

For the time being, the team will keep this issue in the "Freezer" (meaning not under active development), but it does seem like a good and worthwhile idea that the team would like to consider once we get more bandwidth. We're also not opposed to community contribution from somebody like @chingucoding but there would need to be some visual design iteration required as well.

[chingucoding]

Would there be any "design" needed for that? Reading the proposal, it seems more like we would just want to have some "static" content below the TabViewItem area, that does not get swapped out when switching tabs.

Regarding separating the Tabstrip out of TabView, I am inclined to say it wouldn't be that beneficial, since you can just render a TabView and set the page content to null or limit the height of the TabView. However I can't think of a case where you would only need the TabStrip, and if anybody has use cases for that I would love to hear them!

@stmoy @ranjeshj Would you be fine with me doing the next step here and create an API proposal or start implementing this feature?

[mdtauk]

• How would the visual design of this feature work with the existing TabView (where the selected tab's background seamlessly blends into the page background)?

Edge and Chrome use the same Selected Tab Background colour for the Toolbar Background. The Terminal should be able to provide some thoughts as to how this proposal may affect them.

• Would it be beneficial to separate the TabStrip component out of the TabView entirely and make it its own usable widget?

A future Ribbon may have a use for a TabStrip without the view (come to think of it a Pivot without the PivotItem Views could also be used for a ribbon - if the Views and Pivot Strip were also separated)

• Are there specific customers that would use this feature, or is this more of a "nice to have"?

Terminal and whoever is working on the Windows 10X and Xbox Shells could offer some insight also.

---

Would there be any "design" needed for that? Reading the proposal, it seems more like we would just want to have some "static" content below the TabViewItem area, that does not get swapped out when switching tabs.

Aligning to Edge, would mean coming up with a set of styles for buttons, drop downs, flyouts etc for the content of this toolbar area - similar to how the ApplicationBar and CommandBar - use their own button styles.

Regarding separating the Tabstrip out of TabView, I am inclined to say it wouldn't be that beneficial, since you can just render a TabView and set the page content to null or limit the height of the TabView. However I can't think of a case where you would only need the TabStrip, and if anybody has use cases for that I would love to hear them!

Ribbon, Document Views, Property Panels in say an IDE or document app like Photoshop?

@stmoy @ranjeshj Would you be fine with me doing the next step here and create an API proposal or start implementing this feature?

Even if work does not begin in earnest, it could be pegged to a TabView 2.0 or 3.0 timeframe, and the API can be discussed and finessed in the meantime.

[chingucoding]

Aligning to Edge, would mean coming up with a set of styles for buttons, drop downs, flyouts etc for the content of this toolbar area - similar to how the ApplicationBar and CommandBar - use their own button styles.

So essentially TabView should provide it's own "CommandBar" here?

Ribbon, Document Views, Property Panels in say an IDE or document app like Photoshop?

But would they ONLY need the TabStrip but not the complete TabView? After all, when having a TabStrip, you also need to switch the content underneath it when a tab gets selected. And in a lot of cases, I think it would be easier to let the TabView handle it, then to only use a TabStrip and implement the switching logic on your own.

[mdtauk]

Aligning to Edge, would mean coming up with a set of styles for buttons, drop downs, flyouts etc for the content of this toolbar area - similar to how the ApplicationBar and CommandBar - use their own button styles.

So essentially TabView should provide it's own "CommandBar" here?

Ribbon, Document Views, Property Panels in say an IDE or document app like Photoshop?

But would the ONLY need the TabStrip but not the complete TabView? After all, when having a TabStrip, you also need to switch the content underneath it when a tab gets selected. And in a lot of cases, I think it would be easier to let the TabView handle it, then to only use a TabStrip and implement the switching logic on your own.
You make a good point. Having the TabStrip as a primitive used by a TabView control is a componentisation of the control, and could be useful for future controls or future uses.

Whether it is worth the effort of re-architecting the control is for better people than me to decide.

The theory of it sounds sensible, but lots of theories sound good, without practical purpose 😛

[MarkIvanDev]

How would the visual design of this feature work with the existing TabView (where the selected tab's background seamlessly blends into the page background)?

As a part of the TabStrip, it's default background could be set to the same background as the selected tab's background. But as this is just a static content, the developer could set its background to anything.

Would it be beneficial to separate the TabStrip component out of the TabView entirely and make it its own usable widget?

I don't think separating has immediate benefits and it is not necessary to this proposal. Again, when I made this proposal, I was just thinking about being able to add some static content below the tabs that does not get swapped out when changing tabs.

Are there specific customers that would use this feature, or is this more of a "nice to have"?

I am planning to convert my Jump Point app into a tabbed UI. And this feature is one that I would use. In my case, I would use this content as a place for common commands that can be used in all of the tabs and other static content such as blocks of text.

[MarkIvanDev]

So essentially TabView should provide it's own "CommandBar" here?

I don't think it's necessary for the TabView to have its own flavor of a CommandBar here. The TabStrip content should be able to house any type of content not just commands. It will be kind of limiting and complex in terms of layout and styling if the TabStrip content will only accept a CommandBar

If the developer wanted to have this kind of look, we could simply add a Ribbon control here, if that control gets pushed through, and it could still serve the same purpose with a more consistent look with all apps using the Ribbon control

[chingucoding]

I don't think it's necessary for the TabView to have its own flavor of a CommandBar here. The TabStrip content should be able to house any type of content not just commands. It will be kind of limiting and complex in terms of layout and styling if the TabStrip content will only accept a CommandBar

If the developer wanted to have this kind of look, we could simply add a Ribbon control here, if that control gets pushed through, and it could still serve the same purpose with a more consistent look with all apps using the Ribbon control

So to clarify, it would just be a contentpresenter, no additional controls we would introduce with this proposal, right?

[MarkIvanDev]

@chingucoding Yes, basically it is just a contentpresenter. I think the additional controls (the command-type controls mostly) is better suited to be added to the Ribbon control proposal. As the Ribbon is the best place to house those type of controls

[chingucoding]

Ah thanks. Another thing we could also explore would be something similiar to what broswers have underneath the tapstrip, though that would heavily limit the flexibility of the "below content" area. I am not sure if there are any other concerns that need to be addressed right now, what do you think @stmoy?

[stmoy]

Thanks @MarkIvanDev @chingucoding @mdtauk! Some thoughts in no particular order:

I don't think it's necessary for the TabView to have its own flavor of a CommandBar here. The TabStrip content should be able to house any type of content not just commands.

So to clarify, it would just be a contentpresenter, no additional controls we would introduce with this proposal, right?

@chingucoding Yes, basically it is just a contentpresenter. I think the additional controls (the command-type controls mostly) is better suited to be added to the Ribbon control proposal. As the Ribbon is the best place to house those type of controls

+1 to this train of logic. If we added another content area, I'd expect that it wouldn't be "opinionated" (ie. it could support any content). I've seen several proposals for types of content that would go in here - everything from a CommandBar to a TextBox to an InfoBar control. The control wouldn't dictate the type of content.

I am planning to convert my Jump Point app into a tabbed UI. And this feature is one that I would use. In my case, I would use this content as a place for common commands that can be used in all of the tabs and other static content such as blocks of text.

Awesome! I will pass this info along to the team. Is this the correct app? https://www.microsoft.com/en-us/p/jump-point/9pl7b4pz0hs0

Edge and Chrome use the same Selected Tab Background colour for the Toolbar Background. The Terminal should be able to provide some thoughts as to how this proposal may affect them.

@mdtauk - exactly right. Naively, my expectation is to have the selected tab blend into the content beneath it; the heart of my question is "how can we do that"? In TabView today, the selected tab uses the default background color of the page to make a seamless blend. When any custom content (like a toolbar, an infobar, etc.) can be put between the selected tab and the page, how do we know what color to use?

I guess we could keep the defaults the same and just have guidance to set the selected Tab's background color to whatever background color you're using inside the toolbar area. Though then we'd also probably need to tweak the background of the TabView itself to increase contrast. Hrm...

[mdtauk]

@mdtauk - exactly right. Naively, my expectation is to have the selected tab blend into the content beneath it; the heart of my question is "how can we do that"? In TabView today, the selected tab uses the default background color of the page to make a seamless blend. When any custom content (like a toolbar, an infobar, etc.) can be put between the selected tab and the page, how do we know what color to use?

I guess we could keep the defaults the same and just have guidance to set the selected Tab's background color to whatever background color you're using inside the toolbar area. Though then we'd also probably need to tweak the background of the TabView itself to increase contrast. Hrm...

I would add a lightweight style for the Tab Strip Area set to the same colour as the Selected Tab background and foreground colours. This would allow it to be easily changed if need be.

[MarkIvanDev]

@stmoy Awesome! I will pass this info along to the team. Is this the correct app? https://www.microsoft.com/en-us/p/jump-point/9pl7b4pz0hs0

Thanks! Yes, that is the one. But as of now, I am still not pushing out the Tabbed UI, but the work is already underway.

[MarkIvanDev]

Any updates about this?

[stmoy]

Hey @MarkIvanDev - thank you for your patience, no updates yet. The team has been very focused on WinUI 3.0 in the short term, but I'll re-poke the team to see if we can get something done here.

[michael-hawker]

I think the ability to have this inherit the datacontext of the selected item is important as well (like knowing which URL to show in the address bar). A developer can always ignore that if they just want it to be static and fixed to be the same for each tab.