[menu] improve distinction between menubar and toolbar

[josepharhar]

Based on the feedback here: https://github.com/openui/open-ui/issues/1179#:~:text=the%20top%20bar%20is%20a%20menu%20bar%2C%20and%20below%20that%20is%20a%20toolbar

It sounds like we should explicitly say whether the new element we are adding is a menubar or a toolbar, and perhaps link to some aria concept(s).

I think that we are adding a menubar, not a toolbar. I also think that the design we are going for does not preclude us from adding a toolbar element in the future.

Does this sound right @scottaohara ?

[josepharhar]

I also just noticed this from the minutes:

scott: toolbar pattern is important because ? dont allow for quick navigation. toolbars do allow this. if someone wants to jump to a thing they can do that. if theyre all menu items then they cant jump

How do you perform the quick navigation? Is it like a typeahead thing where you type the first letter of the item you want to jump to? Should we implement some keyboard behavior for this?

[josepharhar]

We are already calling the in-page new element a <menubar>, so that is already the best name right? (Since we also want to avoid reusing the existing <menu> element)

[scottaohara]

How do you perform the quick navigation?

this comment was made in context of using a screen reader.

with a screen reader and i come to a toolbar of items - i can use my screen reader's special hot keys to navigate to the type of element I want. e.g., buttons vs other form controls. I can bring up a dialog / rotor of available elements on the page and jump to the one i want.

menuitems do not have these commands. there is no way to distinguish a menuitem from a menuitemradio from a menuitemcheckbox without explicitly navigating to it. Again, where as if i have a toolbar consisting of buttons, checkboxes and a combobox - i can use my screen reader to jump to those individual items, if i know what i'm looking for / dont' want to interact with the "tools" that are of no interest to me at that point.

examples of toolbars are like this github text editor. a toolbar is at the top starting with the H (heading) button and ending with the Slash command button. Or like I was saying in google docs - the bar of controls below the menubar. apg toolbar example. While i'm not a fan of the multiple toolbars used to create one larger toolbar - tiny mce. (menubar at the top for "file" to "help" - what arguably should one toolbar containing various groups but is instead a group containing many toolbars is displayed beneath the menubar)

[css-meeting-bot]

The Open UI Community Group just discussed [menu] improve distinction between menubar and toolbar, and agreed to the following:

• RESOLVED: pursure menubar as part of the menu elements proposal, and leave toolbar as a potential followup element for later. and perhaps the explainer could explicitly say that we aren't proposing a toolbar, just a menubar
• RESOLVED: pursure menubar as part of the menu elements proposal, and leave toolbar as a potential followup element for later. and perhaps the explainer could explicitly say that we aren't proposing a toolbar, just a menubar

The full IRC log of that discussion

<gregwhitworth> domfarolino: there is some discussion of this on the issue, but I don't think it's completely clear between menubar and toolbar
<scott4> q+
<gregwhitworth> domfarolino: is there a command that can be open a popup does it make it a menubar?
<gregwhitworth> domfarolino: there hasn't been too much activity but what are the content model changes that require a completely different element?
<gregwhitworth> ack scott
<lwarlow> q+
<gregwhitworth> scott4: primary distinction is that menubar and menus will have menu items and toolbars can contain a button or will invoke menulist but it can contain various form controls, etc
<gregwhitworth> scott4: a single text field may be at the end and that allows you to use narrow key navigation
<gregwhitworth> scott4: similar to what we were talking about last week, since toolbars can have a variety of elements; someone using a screenreader can navigate them by type (combobox, etc)
<gregwhitworth> domfarolino: that makes sense to me
<gregwhitworth> domfarolino: that feels differently scoped rather than regular than menubar
<gregwhitworth> domfarolino: completely different accessiblity concerns
<gregwhitworth> domfarolino: does that make sense to you scott4
<gregwhitworth> scott4: in the HTML spec, the menu element calls out that it can contain anything
<scott4> the menu element specifically calls out it is a semantic "toolbar" but doesn't behave as a role=toolbar
<gregwhitworth> domfarolino: that sounds good and it feels like the difference of a menubar and a regular menu navigation are similar enough that we would want to ship both at the same time
<jarhar> proposed resolution: pursure menubar as part of the menu elements proposal, and leave toolbar as a potential followup element for later. and perhaps the explainer could explicitly say that we aren't proposing a toolbar, just a menubar
<gregwhitworth> domfarolino: whereas toolbar doesn't sound like it needs to ship
<gregwhitworth> di: I agree, we can keep them seperate
<gregwhitworth> domfarolino: we'll update the explainer to make that more clear
<lwarlow> q?
<gregwhitworth> ack lwarlow
<gregwhitworth> lwarlow: I think toolbar as a new element makes sense as it's pretty distinct from this
<gregwhitworth> lwarlow: I think you could get by minting a new element that has role of toolbar and handles the accessibility but the code to implement it should be basically the same and it's the child elements that will be distinct there
<lwarlow> +1
<sorvell> +1
<scott4> +1
<gregwhitworth> proposed resolution: pursure menubar as part of the menu elements proposal, and leave toolbar as a potential followup element for later. and perhaps the explainer could explicitly say that we aren't proposing a toolbar, just a menubar
<domfarolino> +1
<keithamus> +1
<masonf> +1
<jarhar> RESOLVED: pursure menubar as part of the menu elements proposal, and leave toolbar as a potential followup element for later. and perhaps the explainer could explicitly say that we aren't proposing a toolbar, just a menubar
<gregwhitworth> RESOLVED: pursure menubar as part of the menu elements proposal, and leave toolbar as a potential followup element for later. and perhaps the explainer could explicitly say that we aren't proposing a toolbar, just a menubar
<lwarlow> https://github.com/openui/open-ui/issues/1200

[github-actions[bot]]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.