[menu] Should menulist be a popover by default?

[dizhang168]

We can define <menulist> elements to be popover by default. This would be more natural for developers, but I am not sure if it breaks any semantic. For example, there is no popover=none, so users wouldn't be able to opt out. Maybe we would need to add that as a valid value.

<menubar>
  <menuitem menulist=more>More commands</menuitem>
</menubar>
<menulist id="more">
 ...
</menulist>

<!-- OR -->

<menubar>
  <menuitem commandfor="more" command="toggle-menulist">More commands</menuitem>
</menubar>
<menulist id="more">
 ...
</menulist>

The second option would be to let the developer add the popover attribute and trigger the popover by using command/commandfor. This gives more flexibility to add more commands in the future and allow developers to turn it on/off by removing the attributes.

<menubar>
  <menuitem commandfor="more" command="toggle-popover">More commands</menuitem>
</menubar>
<menulist id="more" popover>
 ...
</menulist>

This is probably related to the openable issue (#1198). If we want to allow inline menulist, than going with command/commandfor would be better.

[dizhang168]

As a side note, if we don't make menulist a popover by default, do we even need a distinction between a menulist and a menubar?

[scottaohara]

menus not being popovers are exceptions to the general expectation. and per my issue you linked to, i wasn't even using an inline menulist - but demonstrating how a menuitem could be used to open a sub-group (fieldset) of menuitems within a parent menuitem.

menulist and menubar would have different default roles and arrow key behavior for the menuitems... making them one just means that'd be other work on the author to make sure they got the behaviors right.

one could make the argument that adding the popover attribute onto the menuwhatever element could then be used to try and adjust the behavior / roles to behave as needed.... but then the popover attribute is changing behaviors to an element, and that'd be an interesting outlier where popover would have additional role / keyboard altering behaviors for this one element, though it doesn't do that for others.

i dunno. i'm not really seeing the positives for a pivot like this.

[dizhang168]

Yes, I was thinking checking if it is a popover would define its keyboard navigation and other differences.

[scottaohara]

so then that'd mean that if anyone had a use case for making a popup menubar, they'd have to know to undo the role/keyboard changes the browser made

[lukewarlow]

I definitely don't think we should merge menubar and menulist regardless of the decision on whether menulist is automatically a popover.

I also don't think we should require authors add popover to menulist. We have precedent for an element that can be in-page Vs a popover, it's select. We didn't require popover there as the switch so I don't think we should here.

If we allow some menulists to be openables we can do some automagic to switch off the automatic popovering.

[scottaohara]

agreed. and i'd again submit that having a menulist be an openable element is not likely to be a common use case.

a menuitem to inline-toggle a group of menuitems within a menulist, may be more common.

[lukewarlow]

Thinking on this more I'm not even sure that it's technically true to say this would be a "popover". I think more accurately it would be an element placed into the top layer, with light dismiss and an associated close watcher. Iirc it has differing behaviour to a standard popover (e.g. I think it should automatically get focus on open). I think it should be considered more akin to a sibling of [popover] much like <dialog> has similarities but also differing behaviour

For example commandfor=menulist would setup an aria-haspopup relationship which it wouldn't do for a standard popover. Obviously we can do that regardless but I think it makes more sense to explain that as a consequence of the element not as a consequence of popover on a specific element.

[josepharhar]

I think that it should just be a popover by default without the attribute so that we can reuse all of the stuff that the popover attribute does for us, like the stacking which we definitely want for nested menulists. We can add focusing and aria stuff on top just like we did for customizable select's picker.

[dizhang168]

Thanks for the feedback. It sounds like we should definitely not require the popover attribute on the menulist element. To start with, we should make menulist use popover semantics. That means the menulist will match on :popover-open, can use hidePopover(), commandfor=toggle-popover, etc.

[lukewarlow]

Idk that it need use the same JS APIs, select is a popover but uses showPicker() for example?

I'm not sure if it should be a new command or not cc @keithamus

[css-meeting-bot]

The Open UI Community Group just discussed [menu] Should menulist be a popover by default?, and agreed to the following:

• RESOLVED: We should not require popover attribute on menulist.

The full IRC log of that discussion

<jarhar> Di: i opened this issue to discuss the popover semantics for menulist. we have agreed that menulist should be a popover, but so far historically popover is a global attribute on any element, and its opt in. this kind of changes that since - if we go with the approach of not setting the popover attribute, and every menulist is a popover, that is
<jarhar> different. i want to make sure that is the approach we are going with. semantics include idl apis such as hidepopover on the menulist element
<jarhar> Di: i think the conversation is leaning towards yes it should be set by default, so that web developers dont need to set the attribute
<masonf> q?
<masonf> q+
<sarah> +1 to default popover
<jarhar> masonf: should it be a popover by default or some other magical concept? idea about it being in the top layer or being a popover. i think it should be a popover because it should interact with popovers in a normal way. dont want to specially define the interactions. i did have a question about - if it is a popover by default without the attribute,
<jarhar> then theres no way today to turn off its popoverness, because the popover attribute has a missing value default which is auto, which means that there is no value for the popover that would make it not a popover. we might need to invent a new value that makes it not a popover
<jarhar> masonf: maybe that isnt needed and theres no use case, fine if menulists are popovers and nobody has to solve that problem
<scott> q+
<jarhar> masonf: should there be different commands for - the command to open a menulist, should it just be show popover or should it be show menu? i would argue that it would be show menu, because i would argue there are behavioral differences like focusing the first item in that menu, but i actually think that it should be a separate value, and we should
<jarhar> preserve the fact that it really is a popover, so showpopover should work on it, and that should be discouraged but still allowed
<masonf> masonf
<masonf> ack mason
<masonf> ack scott
<jarhar> scott: one of the whole reasons that we made popover was so that we could use it for other elements like this. we have the baseline, it should be a popover but someone shouldn't have to use the popover attribute because that would kind of defeat the purpose. i see very few reasons why anyone would need to make a menulist not be a popover, and
<jarhar> reasons that wouldn't be confusing
<jarhar> scott: the only other thing i can think, if someone were to just set it to display:block would that render it inline, and it that also not enough?
<jarhar> scott: im not saying that anyone should be able to use menulist in the page anyway, we have menubar
<jarhar> masonf: i agree with that. you can do display:block, but then when it becomes shown it will go into the top layer and have rendering differences
<jarhar> masonf: maybe you could work around them, but it would really be a pain
<jarhar> q+
<masonf> jarhar: I agree with everything said so far. If you want it in-page, use <menubar>.
<masonf> jarhar: having show-popover and show-menu is funny. But happy to support for now. This'll come up again with standardization.
<masonf> ack jarhar
<domfarolino> q+
<masonf> jarhar: that's the only weird thing about it being a popover by default. Everything else makes sense.
<masonf> jarhar: show-popover and hide-popover is questionable.
<masonf> domfarolino: q is whether we need another command at all?
<masonf> jarhar: maybe just one, yeah
<masonf> domfarolino: that command when applied in a menu context would automatically do "menu" things?
<masonf> jarhar: yeah. We could detect that it's a menu, and do more stuff.
<masonf> jarhar: show-popover could throw an error and say "use menu instead"
<masonf> domfarolino: anne likely has strong opinions about this
<masonf> jarhar: I agree
<Di> q+
<masonf> domfarolino: I see having one command, but cosmetically it looks better to have a menu command
<masonf> jarhar: one more thing: selectlist element listbox part - author had to add popover attribute. Domenic had feedback that it should be automatic instead.
<masonf> ack dom
<masonf> ack Di
<masonf> q+
<jarhar> Di: what mason mentioned about adding a new value for popover like none, it made me wonder if right now i have - always popover auto, do we want to allow other values like hint and manual?
<masonf> ack mason
<jarhar> masonf: i do think, domenic in the selectlist example said the same thing, you should be able to add your own popover attribute and that should be able to override the one you get by deault
<jarhar> Di: does it make sense for menulist to be manual?
<scott> q+
<jarhar> masonf: the use case i could see is that a site wants to manually implement their own behavior like light dismiss
<jarhar> masonf: i dont think its a great use case, but that could be a reason to do it
<jarhar> masonf: the other reason is that the web is like this. something has a default behavior and you can override it. many other attributes are this way, tabindex is like this. some things get a default tabindex, but the attribute overrides it
<masonf> ack scott
<jarhar> scott: i can maybe see an instance of where we have a component library that needs to do something very spectacular with their menu popup and they want to use manual
<jarhar> scott: i agree with you where in cases where it makes no sense you can put attributes on elements and override default behavior. i dont see this as a case where we stop the overriding of default behavior
<jarhar> scott: its just how things work, and it makes absolute trash, but its not called out as something in the spec as something you cant do, then i have to tell people that theyre doing it wrong
<jarhar> q+
<masonf> jarhar: I'm not in favor of adding a new value for popover that makes it not a popover
<masonf> ack jarhar
<jarhar> masonf: +1. that is certainly something that can be added later, assuming the name you pick is web compatible. im in favor of waiting until there is an actual usecase
<jarhar> masonf: to scotts point, it sounds better to discourage that anyway so maybe we dont have to do anything
<Di> resolution: We should not require popover attribute on menulist, menulist are popover by default.
<masonf> +1
<domfarolino> +1
<sarah> +1
<Di> RESOLVED: We should not require popover attribute on menulist.