Microsoft-ui-xaml: Proposal: Vertical TabView

[stmoy]

Proposal: Vertical TabView

Summary

Edge will support vertical tabs in the next few months: https://blogs.windows.com/windowsexperience/2020/03/30/the-top-10-reasons-to-switch-to-the-new-microsoft-edge/

This proposal suggests adding a vertical mode to TabView.

Rationale

• Feature parity with Edge

Scope

| Capability | Priority |
| :---------- | :------- |
| This proposal will allow developers to accomplish W | Must |
| This proposal will allow end users to accomplish X | Should |
| This proposal will allow developers to accomplish Y | Could |
| This proposal will allow end users to accomplish Z | Won't |

Important Notes

Open Questions

[mdtauk]

I have been asking for a TabPlacement option, to allow, Top, Bottom, Left and Right.

With Edge bringing the side tabs back (where chrome ditched them years ago) - we now have a design spec to match to.

[chingucoding]

Love that mockup @mdtauk! One thing we need to thing about: How would this go with the TabViewWidthMode.Compact when in left/right configuration?

[mdtauk]

I would personally like that setting to be disregarded with Left or Right placement @chingucoding. You could have each tab item's width fit the content, but I don't think the pane displaying the tabs should be compact to fit the longest tab. A resizing tab pane width would be off-putting as would each tab not being the full width of the pane.

The Icon only tab mode could be done, sort of resembling the NavigationView's compact mode - but with the Selected Tab having it's distinctive background colour.

Love that mockup @mdtauk! One thing we need to thing about: How would this go with the TabViewWidthMode.Compact when in left/right configuration?

This was a mockup I did when V1 of the TabView was being added to WinUI. But TabPlacement was too much to add in at that time.

[chingucoding]

So to clarify, in Left/Right mode the TabViewWidthMode would be always Equal, regardless of setting. Seems reasonable, since it should behave more like a NavigationView in that case.

My main concern with this feature is the added complexity, because we would then all of the sudden have a feature set that almost would be the same with the NavigationView (without h-nav).

[mdtauk]

If you look at the example from that preview video, there is a new behaviour which added to the drag and re-arrange functionality that NavigationView doesn't have - there is an ability to Multi-Select tabs and move them together.

• Coloured Icons;
• Selected Tab styling;
• The Tab Close buttons;
• The overflow arrows (or should this be a scrollbar);
• Perhaps an option to display tabs rotated;

These all differentiate the two controls.

I think if Edge has this, it should be included in the WinUI control. The NavigationView is for single sections of one app - the Tabs are like a multi-document scenario.

[chingucoding]

The problem I see is not having same features like NavigationView, but rather the complexity that will get added to the TabView. And if we look at the NavigationView, you will see that it's a HUGE code base. Should TabView also move in that direction?

However those are pretty cool features, and in productivity scenarios those can really add more value to applications (imagine Terminal using such features).

[ranjeshj]

I had the same question about NavigationView and this control. Just as an FYI, one decision that caused a lot of complexity with the NavigationView is that the Top and Left behaviors being different (scrolling vs overflow popout)

[mdtauk]

Quick design comp

[duke7553]

An idea we're experimenting with in Files is a vertical tabs Flyout