Who is planned to work on the WinUI Ribbon control, they may have some asks which should be considered?

@mdtauk good call. I could see the Ribbon as containing a TabView as it's a very similar paradigm. It'd be nice to re-leverage components for compositing in this manner.

I could also see some goodness come with Ribbon and docking. Referencing #668

Could there be a lightweight mode for things like Tool Palettes and Dialog Tabs.

Who is planned to work on the WinUI Ribbon control, they may have some asks which should be considered?

@mdtauk, good question. #168 tracks the Ribbon feature. As of right now, the Ribbon is in the "freezer". That said, I did a basic ribbon prototype using TabView v1 as the building block. Here is a really rough, really old proof of concept screenshot using a prerelease TabView from a few months ago:

This issue tracks potential improvements to TabView, of which Ribbon might have special requirements. Since Ribbon is in the "freezer" however, we shouldn't tightly couple these two topics.

@stmoy What do you think of rounding the inner corners of the tab?

Looks nicer & more consistent to me than just rounding on the outside. It would also make us more consistent with new Edge browser.

@stmoy What do you think of rounding the inner corners of the tab?

I love this look! I added this to the table above. We did some preliminary investigation of this particular visual and determined that it was too difficult to "get right" for the v1 release of the control, but I'd love to take another look for v2.

@shaheedmalik i think thats normal behaviour so it's easy to drag tabs and the 1px line is the active window border

Also, dragging tabs with the current implementation doesn't feel nice.

It would be better if other tabs that are not selected/being dragged don't shrink or become "inactive" (greyed out). It should also snap to the tab strip so that there needs to be some force to create a new window. Chrome/Chromium/Edge (Anaheim) are like epitome of tabs :p

TabView Unintended ListView Behavior

@stmoy In my app scenario, we have an ObservableCollection containing InstanceTabItem class objects which each contain a property for the Content. This collection is binded to the TabItemsSource property. The Content property contains a Frame that becomes the content of the TabView ContentPresenter. However, I noticed that closing each TabViewItem won't release the memory used by the InstanceTabItem's content property even though it is completely removed from the collection. In fact, the Loaded event for the TabViewItems themselves is only called one time. Meaning that closing the TabViewItem does not unload/dispose it. This behavior implies that the TabView must have some kind of virtualization mechanism used to recycle items which has the unintended consequence of not destroying the TabViewItem content when closed. Hopefully, you can see how this is a problem for my application scenario. Considering we're on the subject of removing/modifying unintended ListView behavior from the TabView, I wanted to ensure this was noted.

Open questions:
Is ListView virtualization needed for the TabView, if so how can I disable it or prevent this issue?

Should there be an easy way to disable virtualization for the TabView?

Is there a better way I can associate a Page's content with each tab and display it in the TabView ContentPresenter when selected?

Not sure if this is the correct issue, but...

I would like to be able to use only the TabStrip from the TabView.

Scoping Update (Jan 13, 2020)

Hi all! I wanted to provide a quick update on this. Thank you to everyone who provided their input and ideas! I have taken these ideas and pitched them to our team to see what is in scope for the next version of WinUI.

Several of the ideas that we liked the most were the ones that improved the overall polish and user experience of TabView. One of our original goals was to try to make TabView feel as good as what you see in browsers and we've found that the current implementation doesn't yet meet up to that goal. The primary reason is that TabView was built using a specialized ListView "under the covers" which restricted our ability to get some of the fit-and-finish features that we really wanted.

To that end, we're going to swap out the ListView implementation to one based on the more flexible ItemsRepeater instead. In doing so, we expect to be able to tackle several features that were previously blocked - namely around animations and drag-and-drop. This also means that we won't get to everything on the list since this will be a fairly hefty rewrite.

I have modified the issue above to reflect the set of features that we expect to get to in 2.4 vs. the features we won't be able to get to right now. As with all planning exercises, this came with some painful cuts - but my hope is that we'll be better set up to get to these features post 2.4 once we have a more robust foundation to build upon.

@ToddThomson If you don't give any of the tab items content, then the tabs will just be on their own, so it should allow you to just use the tabs.

@stmoy if the corner rounding is just exposed as a resource, then it could be modified, so that way a developer could easily re-template or fake having bottom tabs until the tab location property is implemented.

@stmoy I also just noticed that TabView uses IconSource vs. the NavigationView's Icon (IconElement). Will this be better aligned in WinUI3?

It is handy to just be able to put Icon="Home" for simple construction and then elaborate the IconSource with a complex type if needed.

@stmoy we also have #1999 similar to #1511 we should make sure that both closing and opening animations get updated with vnext.

Something that might be worth exploring and @Felix-Dev and I discussed on the UWP Community Discord is the ability to change the keyboard accelerator for closing tabs. For example, some developers might want to use the same hotkey as Edge for closing tabs, which currently would be a bit hard to implement.

@chingucoding @Felix-Dev

Agreed that developers should be able to set/change/customize the keystrokes that a user pushes to close a tab. The way that we recommend apps achieve that behavior today is documented in the TabView Keyboarding Guidance Doc

I'm not at all opposed to making this easier for app developers, but it is an area that could use more thought as I don't know offhand how best to expose this API. Do you have ideas? It might be worthwhile to file a new GitHub issue tracking this specifically.

@stmoy Thank you for linking the document. We currently have three in-built keyboard accelerators for the TabView control:

• Ctrl+F4 which closes the selected tab (note that the document recommends the developer to use Ctrl+W. We should probably address this (either by updating the in-built close tab keyboard accelerator to (also) use Ctrl+W or change the documentation to recommend Ctrl+F4).
• Ctrl+Tab which selects the next tab
• Ctrl+Shift+Tab to select the previous tab

Since we already have these three in-built keyboard accelerators....perhaps we have to increase the scope of our thinking here. Why not

• add an in-built keyboard accelerator for adding a new tab (defaulting to Ctrl+T)?
• add in-built keyboard accelerators for selecting specific tabs or fast jumping to the start and end of the tab list?

Potentially adding all these into the TabView control itself could considerably increase the in-built commands which would have to be made customizable to the developer. This could affect the approach we decide to choose.

Having said that, I'm not sure if we should add all the Ctrl+[Num] accelerators, but it feels strange to me that we have an in-built shortcut to close a tab, but not to open a tab. I think we should at least add an in-built keyboard shortcut to open a new tab.

The easiest approach to give a developer a customizable tab keyboard acccelerator experience would probably be adding individual properties for each of in-built accelerators we want to expose for customization:

• TabCloseButtonKeyboardAccelerator : Windows.UI.Xaml.Input.KeyboardAccelerator

If we want to make every in-built keyboard accelerator customizable, we would add two more properties then:

• SelectNextTabKeyboardAccelerator : Windows.UI.Xaml.Input.KeyboardAccelerator
• SelectPreviousTabKeyboardAccelerator : Windows.UI.Xaml.Input.KeyboardAccelerator

Open Questions

If we make in-built keyboard accelerators customizable, do we allow developers to set no keyboard accelerator at all? Currently, there always is an accelerator for closing a tab or scrolling through the tab list. However, all other potential interactions (such as adding a new tab or jumping to first/last tab) can either have a keyboard accelerator or can not. That's up to the developer.

If we allow developers to unset the in-built keyboard accelerators (i.e. no accelerator at all to close a tab) this would introduce a significant change to the current standard TabView behavior.

If we disallow developers to unset in-built keyboard accelerators we could fall-back to the current in-built ones in case the developer did not set a valid keyboard accelerator.

@stmoy Thanks for linking that document! Those ways to add new keyboard accelerators seem feasible for most devs.

One problem I see however is, what one should do if they already use Ctrl+F4. From what I can see, it currently is not possible to unassign a keyboard accelerator. So developers are need to ensure that they don't use Ctrl+F4 anywhere else, which may be a bit problematic.

I agree with @Felix-Dev , adding keyboard accelerator properties might be the easiest way, and probably also one of the more intuitive ways to handle that from a user experience.

One problem I see however is, what one should do if they already use Ctrl+F4. From what I can see, it currently is not possible to unassign a keyboard accelerator. So developers are need to ensure that they don't use Ctrl+F4 anywhere else, which may be a bit problematic.

• add an in-built keyboard accelerator for adding a new tab (defaulting to Ctrl+T)?
• add in-built keyboard accelerators for selecting specific tabs or fast jumping to the start and end of the tab list?

These are interrelated. Since there isn't a good way to unassign a built-in keyboard accelerator, we deliberately did not build-in very many accelerators in case the app is already using a particular key combo.

it feels strange to me that we have an in-built shortcut to close a tab, but not to open a tab

Agreed and we spent a bunch of time debating this topic. As above though, this was a deliberate omission. We added the accelerator to close a tab because this combo was one that accessibility users rely on and it seemed obscure enough that it wouldn't conflict with an app's shortcuts if they had any defined. CTRL+T seemed more common, and we didn't want to conflict.

Before we add more built-in keyboard accelerators, I think we need to figure out how to let apps unset/disable them so that they can do so if the shortcut is already being used by the app.

That said, I don't think it's _that_ difficult to add shortcuts to the TabView by following the docs/guidance. In other words: I don't know if this is a problem that needs to be solved right now.

With unassigning keyboard accelerators being not easy, I think the current behavior is fairly good. Unless we have an easy way to remove existing keyboard accelerators, I think it is best to refrain from adding to many accelerators, as @stmoy correctly pointed out.

And adding new keyboard accelerators is not that difficult provided one has read the docs so maybe this is not an area where we need to do that much.

@chingucoding yeah, if there's a sample that shows adding extra keyboard shortcuts for interacting with tabs at the application level or the individual tab level, that'd be useful to resolve some of these concerns.

Maybe there needs to be a separate proposal for a better way to have keyboard accelerators that can be exposed and overridden as part of styles or templates or something?

Could we expect acrylic and reveal brushes in the new TabView? The current design of TabView is NOT "fluent".

Also, setting style or background for TabViewItem doesn't take effects.

Some of these are older examples back when Sets was being announced, and before chromium Edge - but it shows how Tabs could use Fluent Acrylic and the Title Bar area to give a great UX

Here is an example of acrylic being used in Tabs in Files UWP.

@yaichenbaum That example is more of a WinUI XAML Ribbon, but yea, Acrylic and Tabs.

@mdtauk It happens to include a ribbon, but the main point is the tabs at the top.

@mdtauk It happens to include a ribbon, but the main point is the tabs at the top.

I was pre-empting any comments trying to vote down allowing Acrylic, with arguments about Ribbon vs Tabs

Will there be support added to the TabView for handling Dual Screen UIs?

Wrapping the collection of Tabs into two groups with the hinge width between them when an app is stretched across both screens?

Maybe look at how Edgium is handling things, if there is not an immediate obvious way to handle it.

🦙 Link to new Vertical Tabs issue #2194

Regarding the issue mentioned above, is that in scope for the next version?

So as Edge allows for Tabs with PWA windows, we see a new style for the Tab bar, using a chosen colour.

Does TabView need to offer a style option to allow for an Accent colour to be used.

Terminal may benefit from any steps in this direction, as it hopes to add XAML themeing options for the user - or to allow for the user's choice of a coloured TitleBar to work with TabViews extending into the title bar area.

So as Edge allows for Tabs with PWA windows, we see a new style for the Tab bar, using a chosen colour.

Does TabView need to offer a style option to allow for an Accent colour to be used.

With the current version of TabView, you can change all necessary colors to achieve the same effect as the screenshot you shared. This can be done through lightweight styling (overriding specific brushes), making it fairly simple to implement for devs.

@mdtauk Is your idea to provide a single color property and the TabView automatically calculates the hover, selected, clicked and default colors for the TabView? This could create issues with lightweight styling since you would need to decide when to use which resource, which might cause confusion.

So as Edge allows for Tabs with PWA windows, we see a new style for the Tab bar, using a chosen colour.

Does TabView need to offer a style option to allow for an Accent colour to be used.

With the current version of TabView, you can change all necessary colors to achieve the same effect as the screenshot you shared. This can be done through lightweight styling (overriding specific brushes), making it fairly simple to implement for devs.

@mdtauk Is your idea to provide a single color property and the TabView automatically calculates the hover, selected, clicked and default colors for the TabView? This could create issues with lightweight styling since you would need to decide when to use which resource, which might cause confusion.

I was thinking more about providing a Style which takes the Accent Colour shades and applies them to the TabView control - making a specific colour would be an a-typical option for this control, even if it would be more flexible than using the system Accent Colour.

It would require code to take the colour, and generate shades to use and calculate the contrast ratios etc.

I was thinking more about providing a Style which takes the Accent Colour shades and applies them to the TabView control - making a specific colour would be an a-typical option for this control, even if it would be more flexible than using the system Accent Colour.

Right, so it would be something similiar like the AccentButtonStyle, just for the TabView. That's definitely a cool idea in my opinion. I'm not entirely sure how easy that would be to justify (e.g. maintenance, RAM impact, alignment with Fluent Design System), but let's wait what @stmoy and @chigy think about this.

I was thinking more about providing a Style which takes the Accent Colour shades and applies them to the TabView control - making a specific colour would be an a-typical option for this control, even if it would be more flexible than using the system Accent Colour.

Right, so it would be something similiar like the AccentButtonStyle, just for the TabView. That's definitely a cool idea in my opinion. I'm not entirely sure how easy that would be to justify (e.g. maintenance, RAM impact, alignment with Fluent Design System), but let's wait what @stmoy and @chigy think about this.

I know Edge is kind of leading the way in directing the TabView control - and this is a new feature where the PWA is able to use tabbed windows, and I believe it can control the Titlebar Color.

Terminal has had lots of requests for a coloured Titlebar, and they plan to implement user XAML theming.

I know Edge is kind of leading the way in directing the TabView control - and this is a new feature where the PWA is able to use tabbed windows, and I believe it can control the Titlebar Color.

Yes, I think having feature parity with edge is something we should aim for.

Terminal has had lots of requests for a coloured Titlebar, and they plan to implement user XAML theming.

Just out of curiosity, could link some of those issues to understand the features that would help them better? 😄

Take a look at this PR (Theming spec): https://github.com/microsoft/terminal/pull/5772

I know Edge is kind of leading the way in directing the TabView control - and this is a new feature where the PWA is able to use tabbed windows, and I believe it can control the Titlebar Color.

Yes, I think having feature parity with edge is something we should aim for.

Terminal has had lots of requests for a coloured Titlebar, and they plan to implement user XAML theming.

Just out of curiosity, could link some of those issues to understand the features that would help them better? 😄

Here are a few
https://github.com/microsoft/terminal/issues/4862
https://github.com/microsoft/terminal/issues/3973
https://github.com/microsoft/terminal/issues/3624
https://github.com/microsoft/terminal/issues/1963

Thanks for the links @mdtauk and @Felix-Dev !

I don't mean to sound rude here, but I do think it needs saying. The current design of the WinUI TabView looks very out of place in UWP apps. It's clearly taken from the Edgium tabs, which are clones of Chrome's tabs. I don't see why we're stealing that style, especially since we already have a Fluent Design UI for TabView in the WCT.

I don't mean to sound rude here, but I do think it needs saying. The current design of the WinUI TabView looks very out of place in UWP apps. It's clearly taken from the Edgium tabs, which are clones of Chrome's tabs. I don't see why we're stealing that style, especially since we already have a Fluent Design UI for TabView in the WCT.

Edgium and Chrome don't use the same Tab design

And the WinUI designers have decided this is the tab style that should be used, and the rounded corners do match with the WinUI values.

Now I suppose some will prefer the previous Edge tab design.

And there was a proposal about providing an alternative style for the control. #2587

Sure, there are small differences between the Chrome and Edgium tab styles, but you can still tell that one is a clone of the other. The average user (including myself at first) can't even tell the difference between the two at a glance. The current design of the tab view is not Fluent Design. In fact, it breaks most of the principles that Fluent Design is based on.

Adaptive: Fluent experiences feel natural on each device

The design feels average on desktop (after all, it is based on Chrome's design), but it's difficult to use with a touchscreen, particularly the close button. It's just too small to hit, even on a 13" display (which is the scale of a small laptop, not even an average-sized tablet). Part of why the WinUI tab view feels out of place is because it's not as touch-friendly as the other controls. The other two platforms mentioned on this page are Xbox and Mixed Reality/Hololens. This design already feels weird when juxtaposed with apps that utilize Fluent Design on desktop. Imagine how much worse that will be when the entire operating system, and all the apps on it, use the original and current official description of Fluent Design? Users always rag on Microsoft for UI inconsistency, why give them another reason?

Empathetic: Fluent experiences are intuitive and powerful

Both the current WinUI/Edgium and WCT tab views do this really well, good job!

Beautiful: Fluent experiences are engaging and immersive

The docs page I linked to earlier lists these five "pillars" to achieve this: light, shadow, motion, depth, and texture.

Depth & Shadow

The current WinUI/Edgium design has some depth because of the added shadows to the edges of the tabs. It's not much, but it doesn't have to be. As for depth in general, the docs specifically reference parallax to create depth. This isn't really practical for a tab view, as there's no background image or anything.

Light

In Fluent Design, light is typically used to highlight when something is clickable. That's why controls like Buttons, AppBarButtons, and NavigationView use reveal highlight on both their backgrounds and borders. This is something the WinUI tab view doesn't have at all. Even Chrome's tabs have a slight reveal-like effect when you hover over them. As it stands, there really isn't anything visual to hint that these tabs can be interacted with. There should at least be some reveal on the border of the tab.

Motion

The current design also has some motion, particularly when tabs are dragged. (It is quite buggy, both visually and technically, but those are separate issues that have already been filed and are being improved upon.) The only other place to add motion would be the content of the tab view. Right now, tab content just appears in place without any transitions. Maybe there could be a default content transition in the template, like what the NavigationView does.

Texture & Material

The only texture/material that applies here (and really the only one that exists in Fluent Design) is acrylic. Legacy Edge used acrylic for the title bar/tab view background, which was really nice, but not everyone liked it. The WinUI tab view allows developers to decide whether or not to use acrylic as the background, which we devs (including me) greatly appreciate.

TL:DR; The WinUI/Edgium tab view look too much like Chrome's tabs and don't follow several of the key principles of Fluent Design. It's comfortable with a mouse and keyboard on desktop, but odd on large touchscreen devices and downright unusable on Xbox, Mixed Reality, and Mobile (or a mobile-sized device). The tabs also look very static because they lack light, which can easily be solved by adding reveal along the border of the tab (and possibly on the tab background too).

WinUI 3 at launch will not support Acyrlic HostBackdrop or Reveal. I would imagine once WinUI 3 does support these things, the Windows 10 version of Edge, may adopt them.

@yoshiask I don't even know anymore what is still Fluent Design and what is not. Consider in-app acrylic: Looking at WinUI, it seems that on Windows, transient UIs like context menus and flyouts should use in-app acrylic by default. The NavigationView pane also uses in-app acrylic when displayed as an overlay. Furthermore, the official documentation states the following regarding when to use acrylic:

This, again, is matched by the default look of the controls shipped with WinUI which "embodies Fluent Design".

Yet, just a few days ago, the Microsoft Edge team proclaimed the following:

[...] you’ll note that the new version of Edge is aligned with the current direction Fluent is going [...]. Another example is that there isn't a pivotal focus on transparency in the latest Fluent designs, and surfaces of the new version of Edge reflects this.

Yet none of the transient UIs in Edge browser use in-app acrylic, like context menus:

So...this begs the following questions:

• Is Edgium using a newer iteration of Fluent Design than WinUI on Windows? Is in-app acrylic used as a background for transient UIs like context menus already outdated and to be replaced with a solid background color?
• If not, why is the Edgium team apparently saying Edgium in Windows 10 is already "Fluent Design'ed" when one of the pillars of Fluent Design - Acrylic - is missing everywhere in the browser? And it does not seem they plan to add in-app acrylic to the browser's transient UIs?

I personally believe the Edge team just didn't want to go through the task of recreating the acrylic effect they got for free when they shipped Edge UWP. But in that case, I would welcome it if they were honest enough to say it like that, and not act like in-app acrylic for transient UIs is no longer the default for Fluent Design on Windows.

Their comment on the transparency aspect in Fluent Design and how Edgium reflects this, is - based on WinUI and the official documentation - just not accurate. Plain and simple. Their transient UIs should ship with in-app background acrylic. They do not. For whatever reason.

Perhaps Edium uses the newest Fluent Design iteration and WinUI will soon follow suit? Perhaps in-app acrylic and reveal effect will soon no longer be part of Fluent Design? If that were the case then yes, Edgium would indeed be implementing the pillars of Fluent Design the Edgium team proclaims it does.

I didn't mean to shift the conversation to Edgium's design in general. I just wanted to point out that we seem to be taking cues from the Edgium tab design when there's absolutely no reason or benefit for it. This is WinUI, and it's running on Windows 10. I get that WinUI 3 doesn't have host backdrop acrylic right now, but 2.x does. On top of that, both versions have reveal and are meant to be touch-friendly.

I didn't mean to shift the conversation to Edgium's design in general.

@yoshiask Yes, I'm aware of that. The point of my comment above is that perhaps Edgium is already following the newest Fluent Design iteration we just aren't aware of it yet. Perhaps in-app acrylic and reveal are just no longer important to Fluent Design. At least the blog post by the Edge team linked above seems to suggest that.

That said, I would love if reveal effects could be added to the TabView's tabs and buttons (like in Edge UWP). But I don't know if that is matching the most up-to-date Fluent Design guidelines any longer.

(Note: The TabView scroll buttons are using reveal currently. Why just them? Why not expand that to the other TabView UI elements as well?)

Here's a concept of how Edge should look.

https://www.reddit.com/r/Windows10/comments/hwsgyc/so_its_been_more_than_a_year_since_we_got_the/

The acrylic makes it look cleaner, but it still isn't really Fluent. The UI layout hasn't changed at all, and the close buttons are still just as difficult to tap.

The acrylic makes it look cleaner, but it still isn't really Fluent. The UI layout hasn't changed at all, and the close buttons are still just as difficult to tap.

So what you are asking for is a larger touch target for the close button?

Touch hit target areas should generally be 40x40 pixel sized in WinUI to my understanding (we can see those used for the NavigationView/TreeView chevron and the NumberBox Popup spin buttons). Values like a min height of 32px are also sometimes used (see for the example the Checkbox). While a hit target area of 40x40px or 32x32px for the Close button are problematic given the current TabVíew UI, I did some quick testing and an increase from 16x16px to 24x24px for the hit target area seems possible:

| 16x16px (ccurently) | 24x24px (possible change) |
|----|----|
|||

(I have also adjusted the right margin of the close button in the screenshot above. With the original right margin, it would look like this:
)

@Felix-Dev The Touch Target can be larger than the visual for the hover background - I would argue a touch target of 32x32 with a visual hover of 20x20 would both look good, and function well.

@mdtauk So something like the CheckBox hover visual then (this is a modified checkbox with transparent check background in rest state):

@mdtauk So something like the CheckBox hover visual then (this is a modified checkbox with transparent check background in rest state):

That would aid in finger target size, and not look bad.

Background set to a Transparent brush and the Background TemplateBinding goes onto a new Rectangle used as the Hover/Pressed visual. Focus Visual would be around the 32 x 32 size.

@mdtauk Here is how it could look like then (visual hover area is 20x20px):

with the hit target area (32x32px) shown in red below:

The Close button currently does not participate in tab stops, so there is no Focus Visual to my understanding, but if it were to participate, it could look like this:

What do you think?

Looks good to me. I'm sure it would need to be looked at by the design and accessibility teams to make sure it functions well for those audiences.

Yeah, perhaps the margin between the TabViewItem's ContentPresenter and the 'x' symbol could be reduced a bit further (especially if there is no Focus Visual which needs to be kept in mind for now). Pinging @stmoy here for overall thoughts on the above discussion.

Edit: Here is a screenshot showing a slightly reduced margin (compare it with the screenshot/GIFs above):

The acrylic makes it look cleaner, but it still isn't really Fluent. The UI layout hasn't changed at all, and the close buttons are still just as difficult to tap.

What kind of UI Layout changes did you have in mind - supposing the Touch Target for the close button were to change?

I transposed the touch targets of Modern IE on Windows 8.1 on to the tabs of Tabview and came up with this.

Here's it with a 40x40 touch target.

The acrylic makes it look cleaner, but it still isn't really Fluent. The UI layout hasn't changed at all, and the close buttons are still just as difficult to tap.

What kind of UI Layout changes did you have in mind - supposing the Touch Target for the close button were to change?

Touch targets are what I have the biggest issue with. The proposals for the close button look great, but the new tab button has the same issue. That's really all I can put into words; the current design just doesn't feel as Fluent Design as the WCT one, but I can't really describe why.

Here's a mockup with a 20x20 new tab button and 20x20 close buttons.

Here's a mockup with a 20x20 new tab button and 20x20 close buttons.

The Close glyph feels oversized

The Close glyph feels oversized

I don't really like it either. It should be like 17x17 maybe.

@stmoy some of these have been addressed now, eh? Should this issue be closed or updated to factor in current thinking of future updates (if any)?