nested structure for menus?

[dbaron]

The biggest concern that came up when discussing advancing the menu elements proposal to stage 2 in the WHATWG is the non-nested structure of the menu elements (using idrefs). See whatwg/html#11729 (comment) and following comments. The main concern seems to be relationship to existing web features (such as event dispatch) that depend in various ways on nesting.

My understanding is that the structure we're currently using matches more of the existing libraries that were evaluated while developing the proposal.

So I'm opening this issue to try to figure out:

• if we went with a nested structure, what would it look like
• what advantages/disadvantages would that nested structure have.

I'll start with what seems to me like a reasonable way to build nested menus.

Consider a simple example the structure we have today:

<menubar>
  <menuitem command=toggle-menu commandfor=file-menu>File</menuitem>
  <menuitem command=toggle-menu commandfor=edit-menu>Edit</menuitem>
</menubar>

<menulist id=file-menu>
  <menuitem>New</menuitem>
  <menuitem>Open</menuitem>
</menulist>

<menulist id=edit-menu>
  <menuitem>Cut</menuitem>
  <menuitem>Copy</menuitem>
  <menuitem>Paste</menuitem>
</menulist>

If I were to turn this into a nested structure, I think I'd turn it into something like this. (For now, please focus comments on the structure and not on the names!)

<menubar>
  <submenu>
    <menulabel>File</menulabel>
    <menulist>
      <menuitem>New</menuitem>
      <menuitem>Open</menuitem>
    </menulist>
  </submenu>
  <submenu>
    <menulabel>Edit</menulabel>
    <menulist>
      <menuitem>Cut</menuitem>
      <menuitem>Copy</menuitem>
      <menuitem>Paste</menuitem>
    </menulist>
  </submenu>
</menubar>

In this proposal, the <menulabel> would be much like a <menuitem> (and it could even be one -- again, please ignore naming for now), but it would be the item that opens the submenu. I think it needs to be in a child element of the <submenu> so that events and states (e.g., :hover) going to the label can be distinguished from those going to the submenu's <menulist>.

If we were to consider nested menu structure, does this seem like the right way to do it? Are there other alternatives we should consider? (Are there existing libraries that use a nested menu structure, and if so, what do they do?)

If we did this, what advantages and disadvantages would it have? Would there be issues with ARIA mappings? Are there other things we should consider?

[lukewarlow]

Is a top level menulist within a menubar really a "submenu" at all? What does this look like in the standalone button with a menu case?

I don't necessarily get why nesting is desired either. If authors built this today they'd use buttons and popover and they use idrefs and don't nest? Idk why this is really any different it's just specific type with more built-in behaviour? Perhaps the submenu behaviours do warrant a different design though. Requiring authors to nest does make it harder to compose but maybe that's not as needed for a menu than a generic popover?

Well the main reason not to do this is because HTML is an hierarchical format and this is inconsistent with it. And requires ID reference management.

Yes but also HTML already has plenty of ID reference management, (e.g. button + popover, input + datalist), then you have patterns like form + input or form + button where they support nesting but then both of those offer an idref approach too, if we offered idref approach too we'd have to solve complexities either way?

In my head this menu relationship is a bit backwards to the ones that use nesting too but perhaps that just because I'm thinking of it more like button + popover. Like the button is nested inside the form or otherwise has a form owner, whereas this is more that a menuitem has an associated "sub/child" menu?

As in I was intepreting "nesting" more like below (not suggesting this is better or should really be considered just that it's an alternative interpretation)?

<menubar>
  <menuitem>
     File
     <menulist>
       <menuitem>New</menuitem>
       <menuitem>Open</menuitem>
     </menulist>
  </menuitem>
  <menuitem>
     Edit
     <menulist>
       <menuitem>Cut</menuitem>
       <menuitem>Copy</menuitem>
       <menuitem>Paste</menuitem>
     </menulist>
  </menuitem>
</menubar>

But perhaps menus are more like a select, than any of the other patterns, where you have the container element, with a child "button" (aka menuitem that triggers submenu) + list of "options" (aka menuitems for the submenu) enclosed within a container element?

But what does that container really give us here? Aside I guess from skipping the idrefs. For a select the container element handles all of the form participation complexities but they don't exist here, it also can create a default button which we don't really get or need here?

I guess the menuitem does give the accessible name to the menulist popover unlike button + popover and I guess closer to select (though select is weird and inconsistent and also the acc tree doesn't have to match the structure from HTML).

If we do the nesting approach via say submenu, how well does this work with shadowdom?

The below doesn't work today:

<form>
   <custom-element><template shadowrootmode="open">
      <input>
   </template></custom-element>
</form>

Nor is there a .formElement property getter/setter to do it via JS.

The below also doesn't work:

<custom-element><template shadowrootmode="open">
<select>
<slot>
</template>
<option>123</option>
</custom-element>

So we should think about how or if this can work with shadow dom.

As it currently stands (assuming referencetarget) you can at least have the menuitem in light dom and link to a menu that's in a shadowdom.

<menubar>
  <menuitem command=toggle-menu commandfor=file-menu>File</menuitem>
</menubar>

<custom-element id="file-menu"><template shadowrootmode="open" shadowrootreferencetarget="inner">
<menulist id=inner>
  <menuitem>New</menuitem>
  <menuitem>Open</menuitem>
</menulist>
</template></custom-element>

The case where menuitems are slotted into a menulist I guess we would need to work out no matter how we do this.

[dbaron]

As in I was intepreting "nesting" more like below (not suggesting this is better or should really be considered just that it's an alternative interpretation)?

I think the important difference between the two trees is that I put an extra wrapper element around "File" and "Edit". I think this is necessary so that there's an element that gets clicks, :hover, etc. for the submenu's item but not for the submenu itself. (Other than that I think the differences are naming, plus which things can be the same element versus need to be different elements -- which is sort of a subcategory of naming.)

Regarding shadow DOM -- I think there's also interesting shadow DOM stuff every time we do things based on the content model. For example, the <menulist> looks at its child <menuitems> (or sometimes grandchild etc., with <div>s in between) -- and normally things in the platform that do something like that seem to look at actual light DOM children and not consider shadow DOM. That actually feels a bit weird to me (coming from CSS land where I think we always do want to consider shadow DOM), but it also seems consistent with the way other things work. Maybe that needs a separate issue...

[css-meeting-bot]

The Open UI Community Group just discussed nested structure for menus?, and agreed to the following:

• RESOLVED: don't support the "nested interactives" version of the tree structure.

The full IRC log of that discussion

<keithamus> dbaron: menu elements proposal to whatnot recently, one result is that they were not happy with the basic element structure
<keithamus> dbaron: I wasn't involved early on so I am not in the best place to defend it but my understanding is that was based on existing userland code
<keithamus> dbaron: we're at the point in the whatnot meetings where we either provide things that break if we're in the nested structure, or switch to a nested structure
<flackr> q+
<keithamus> dbaron: menubars/menulists dont need relation in the dom other than the fact that they aren't children and are idrefed. I think whatnot folks think expressing relationships in html is done by nesting not by idrefs.
<keithamus> Zakim, open queue
<Zakim> ok, keithamus, the speaker queue is open
<flackr> q+
<lwarlow> q+
<nmn> q+
<keithamus> dbaron: 2 proposals for that in issue. Essentially 3 structures in the issue right now. Option A being what we're doing right now. Below that is option B - nested structure, with submenus names in an element and contents in another, with a container.
<jarhar> q+
<keithamus> dbaron: want to focus on structure, not names, not even "is name A same as name B", could be same element name for other things, but I don't want to talk about it yet.
<keithamus> dbaron: option B is a menulabel element, could also be menuitem, we can do naming later. Key difference is inside the submenu you have a name for an element inside the submenu then the list
<keithamus> dbaron: useful for event propagation, states like hover, active.
<keithamus> dbaron: option C is what lwarlow wrote, differing by not having that extra element. Naming aside.
<scott> q+
<keithamus> dbaron: are there good reasons, developer or user or a11y, that we wanted this structure with IDrefs - or can switch to another structure, do we care about which oen?
<keithamus> s/oen/one
<keithamus> dbaron: option C interactive elements nested within eachother, option B are not
<masonf> ack flackr
<masonf> ack lwarlow
<keithamus> flackr: I also raised this concern before, at pointerevents. The not nesting makes pointerup targeting problematic, but nesting makes this really easy. Really simplifies event model. Click is always targeting menu. Can handle click properly without capturing issues
<keithamus> lwarlow: option C was my interpretation of what was in WHATNOT but I don't think it's good, it feels weird.
<keithamus> lwarlow: I think if we do nested, do option B, or something else.
<keithamus> lwarlow: I've done digging for original discussion, part of me thinks maybe in a gdoc, can't find mine or Scott's comments
<keithamus> lwarlow: I know we discussed it
<keithamus> dbaron: I found gdoc but didnt have comment access.
<keithamus> lwarlow: maybe the owner can check? masonf? Dom?
<keithamus> lwarlow: it makes sense because it's just button and popover. Exact same pattern
<keithamus> lwarlow: its how we've done dialog, popover, input + list, label and input,
<keithamus> lwarlow: form and input can be outside, e.g. The idea that it's always hierarchical isn't true.
<keithamus> lwarlow: if I am developing it today I'm using a button, role menulist, command/commandfor and pointing it to a popover
<keithamus> lwarlow: if it's easier to implement nested then I don't have a big problem with ti
<keithamus> s/with ti/with it
<keithamus> lwarlow: seems harder to compose though, have to have submenu, menubar, etc, there from the getgo. Can't have menulists put in DOM at end.
<keithamus> lwarlow: could do that with popovers but can't with menus?
<dbaron> s/menulists put/menulists that are implemented by another team and put/
<keithamus> lwarlow: probably won't work with shadowdom
<masonf> ack nmn
<keithamus> lwarlow: which again, might be fine but something to consider
<keithamus> nmn: I think I'd want option A, all sorts of reasons you dont want the rigid nested structure
<keithamus> nmn: but just like form+input, it could support both, so best combo is A+C, trigger with commandfor, menu that opens the popover, special case could be you could nest menu inside trigger to not need manual id
<keithamus> nmn: that's exactly what option C shows
<masonf> ack jarhar
<keithamus> nmn: if we dont want that I just want A, most flexible
<keithamus> jarhar: we spoke about the nested interactives thing, a popover inside the button that invokes the popover means clicking inside the space fires a click event that bubbles up to the invoker button, so author or browser code to decide whether or not to toggle the menu, has to walk the event path and decide if the click is inside the menu or button.
<keithamus> jarhar: I had to do this and undo this a bunch of times for custom select. I think it's bad, we shouldn't do it
<keithamus> jarhar: nesting without nested interactives seems palatable to me.
<masonf> ack scott
<keithamus> jarhar: I hope whatnot is receptive to option b
<keithamus> scott: I do recall some of the gdoc comments; one of the reasons we went in this direction was based on what developers are doing now. Declare menus outside of menubar/menulist, associate them appropriately. People will just want to inject things. Adding to bottom of dom is sure a hell of a lot easier than knowing where to inject into any X teams
<keithamus> implementation
<keithamus> scott: that all said, menuitems are weird. They're the only interactive element in ARIA that doesn't overtly say you can't put nested interactives inside, solely because nested menus inside of the menuitem
<keithamus> scott: not because any interactive element is allowed inside but because a tree item can contain a group of subtree items
<keithamus> scott: the way forms mode works on windows screenreaders, arrow keys are used, not necessarily in scan mode, the experience is very controlled.
<keithamus> scott: I imagine we went away from it was because we don't want people to nest interactives "except for this case"
<keithamus> scott: "html doesn't work this way" except for all the things that work exactly like that.
<keithamus> scott: I don't seen an issue with supporting both though. nest for encapsulation but also enjoy working on click events for those
<keithamus> flackr: A few people say support both - would people be satisfied with support both if some things don't work in non nested?
<keithamus> lwarlow: if you do both you have to do the hard engineering
<keithamus> flackr: a lot doesn't make sense for disassociated things, if I mousedown in one bar and move to another and mouseup, that shouldn't activate the other menu, it tells you you started and ended it the same menu
<keithamus> lwarlow: thats what idrefs are for
<keithamus> flackr: so you have to follow the chain on mouse events? Thats a lot
<keithamus> nmn: thats the main reason for option B or C, it's super hard to implement today.
<keithamus> flackr: its very awkward, doesn't follow the way events work today
<keithamus> dbaron: just to clarify some of the behaviors - the mouseup, you mousedown on say open file inside file menu, move mouseup, go to edit menu, mouseup on copy, that activates copy on edit menu, even though mousedown was on file menu. The up can be arbitrary
<keithamus> flackr: if you have nested structure they have a common ancestor
<keithamus> flackr: its not like one menu to another menu and mouseup that works, that's weird
<keithamus> lwarlow: whats the complex bit here? doing an action on mouseup?
<keithamus> masonf: it fires a click on common ancestor, some tree element above you
<keithamus> PROPOSED RESOLUTION: discount option C
<masonf> Proposed resolution: don't support the "nested interactives" version of the tree structure.
<lwarlow> Well C is bad but Scott did say aria allows it...
<lwarlow> But yeah B looks better
<keithamus> flackr: c is "let developers struggle if they want to". I dont mind. But we should at least support B
<lwarlow> +1
<dbaron> +1
<keithamus> +1
<masonf> +1
<dbaron> nmn: We could resolve that we don't want options C exclusively.
<jarhar> +1
<nmn> `A, A+C or B` currently?
<masonf> RESOLVED: don't support the "nested interactives" version of the tree structure.
<keithamus> Zakim, please end the meeting

[dbaron]

I updated the explainer to have a section on nesting versus idrefs.

[dbaron]

I'm not sure how much it makes sense to have the discussion in two places at once -- but I just posted whatwg/html#11729 (comment) which is relevant to this issue.