Bugzilla

(In reply to Magnus Melin [:mkmelin] from comment #31)
> I would prioritize
> - Add tests to cover all aspects of the toolbar.
> - Make the `UIDensity` affect this new toolbar.
> - Add an entry point to allow extensions to add buttons.

Sounds like a good a place!

> Instead of <aside> use <div role="toolbar" aria-orientation="vertical"> and manage focus with up/down arrow keys.

Yup, that's planned.

> Add a context menu to the buttons to open the tab in a new window. And, when/if we properly support multiple tabs of the same type in the same window, an option to open a new distinct tab in the same window.

Great suggestion!

> Make the focus styling on the current buttons more obvious.

Yes, the focus styling and navigation will follow mostly what Firefox does in their main toolbar, with Tab to focus on a major area and then arrow keys to loop through the buttons of that area, and the focus ring will be a 2px outline.

> Change the background color and maybe make the inline-end border thicker...

The background color will be customizable. Once I implement that the inline border will be a darker box shadow with opacity, or a pseudo element with opacity on top of the toolbar, so it changes the tint based on the selected background color.

> It looks strange next to the settings navigation...

It doesn't loop too strange to me as I can clearly distinguish their purpose and sections, but you bring up good points so we can explore some better visual separation and organization.

> I think the spaces toolbar should be between #toolbar-menubar and #tabs-toolbar in the document structure and in the tab sequencing. It is currently after the tabs, but the visual reading order is before the tabs.

Welcome to my struggle.
Unfortunately, I was forced to put the spaces toolbar in the "body" after the #navigation-toolbox due to how the structure and styling are done to build our "header" area and render the window decorations in every OS.
Having the spaces toolbar physically in the navigation toolbox made it impossible to span the full height of the application since the header box and the tabmail box are separate entities.
You're more than welcome to give it a try if you can find a solution.

> I'm a little bit concerned about always having both the "spaces" toolbar and "tabs" bar, since the tab functionality is split between them. One opens tabs, the other is needed to close tabs, but both can be used to switch tabs.

This is a transition state.
If you recall from my design system presentation, the long term goals is to less and less rely on tabs for our primary sections (mail, calendar, chat, etc). So yeah, it's weird right now, but it will improve and change with time and mostly follow what you suggested.

(In reply to Magnus Melin [:mkmelin] from comment #31)
> I would prioritize
> - Add tests to cover all aspects of the toolbar.
> - Make the `UIDensity` affect this new toolbar.
> - Add an entry point to allow extensions to add buttons.

Sounds like a good a plan!

> Instead of <aside> use <div role="toolbar" aria-orientation="vertical"> and manage focus with up/down arrow keys.

Yup, that's planned.

> Add a context menu to the buttons to open the tab in a new window. And, when/if we properly support multiple tabs of the same type in the same window, an option to open a new distinct tab in the same window.

Great suggestion!

> Make the focus styling on the current buttons more obvious.

Yes, the focus styling and navigation will follow mostly what Firefox does in their main toolbar, with Tab to focus on a major area and then arrow keys to loop through the buttons of that area, and the focus ring will be a 2px outline.

> Change the background color and maybe make the inline-end border thicker...

The background color will be customizable. Once I implement that the inline border will be a darker box shadow with opacity, or a pseudo element with opacity on top of the toolbar, so it changes the tint based on the selected background color.

> It looks strange next to the settings navigation...

It doesn't loop too strange to me as I can clearly distinguish their purpose and sections, but you bring up good points so we can explore some better visual separation and organization.

> I think the spaces toolbar should be between #toolbar-menubar and #tabs-toolbar in the document structure and in the tab sequencing. It is currently after the tabs, but the visual reading order is before the tabs.

Welcome to my struggle.
Unfortunately, I was forced to put the spaces toolbar in the "body" after the #navigation-toolbox due to how the structure and styling are done to build our "header" area and render the window decorations in every OS.
Having the spaces toolbar physically in the navigation toolbox made it impossible to span the full height of the application since the header box and the tabmail box are separate entities.
You're more than welcome to give it a try if you can find a solution.

> I'm a little bit concerned about always having both the "spaces" toolbar and "tabs" bar, since the tab functionality is split between them. One opens tabs, the other is needed to close tabs, but both can be used to switch tabs.

This is a transition state.
If you recall from my design system presentation, the long term goals is to less and less rely on tabs for our primary sections (mail, calendar, chat, etc). So yeah, it's weird right now, but it will improve and change with time and mostly follow what you suggested.