[menu] do we need special behaviors and thus special markup for <button>s that invoke <menulist>s?

[dbaron]

In whatwg/html#11729 (comment), whatwg/html#11729 (comment), whatwg/html#11729 (comment), and whatwg/html#11729 (comment) we had some discussion about what the pattern should be for <button> elements that open a <menulist>, in particular as a result of the changes from #1456. (I think it was mostly me and @lukewarlow though I think @scottaohara was also interested.)

The current state of the explainer following the changes for #1456 is that I've only made the small change from command=toggle-menu to command=toggle-popover so that the pattern for a <button> that opens a <menulist> is now:

<button command=toggle-popover commandfor=mymenu>
<menulist id=mymenu>
  ...menuitems go here...
</menulist>

or maybe even:

<button popovertarget=mymenu>
<menulist id=mymenu>
  ...menuitems go here...
</menulist>

I was thinking this was fine because buttons invoking menus didn't need any special behavior, and it would be fine if all of the special behavior were inside the <menulist> which is a popover.

One thing @mfreed7 asked me about yesterday is whether that's actually correct. In particular he suggested that we probably want to support the gesture involving:

1. user mousedown on the <button>
2. menu opens
3. user moves mouse to a menuitem
4. user mouseup on the menuitem activates it, including firing of click event (see [menu] Should an event be fired when a <menuitem> is selected? Which event? #1312)

This is a special behavior that isn't automatically implied by the above markup. And, in particular, the solution that the pointer events experts we've talked to so far are suggesting for #1312 is that we do event retargeting similar to what is done for the <label> element, which requires that we have an ancestor-or-self of the normal target of the click event (which is the nearest common ancestor of the mousedown element and the mouseup element). So if we want to do this we probably need a menu-specific element that contains both the <button> and the <menulist>. @mfreed7 suggested that <submenu> might be appropriate.

So I guess then the question is whether we should consider doing this. We could consider wrapping something like the above in a <submenu>... and then maybe also removing the markup above and making the <submenu> imply the invoking behavior just like it does for <menuitem>.

Thoughts?

[lukewarlow]

I like the simplicity of the current approach, I don't know what others from whatwg will make of it.

If we think we really do need the special behaviour then maybe the container is fine?

One pattern I've seen that the nesting in a container pattern in general makes harder is the ability to have a single menulist element that you populate during the beforetoggle event. Instead you need potentially alot more Dom nodes for essentially duplicate menus, or you can lazy fill the menuitems but still need the wrapper menulist duplications.

[scottaohara]

a button that invokes a menu generally doesn't behave the same as a submenu invoked from a menuitem in a menubar, per the behavior being described here. see the various instances of buttons that open custom ARIA menus here in this github interface, where the menu popup doesn't appear on mouse down. this is the behavior i'd expect for menulists invoked by buttons.

now, if people wanted this special behavior, then sure? maybe some kind of grouping element could be created to wrap the button and the menulist it will invoke to help allow for this? but the element itself would have a role of none or generic in the accessibility tree. so why not just a div with an attribute or JavaScript to make this special behavior for this use case, then?