[menu] support :open pseudo-class on <menuitem>s that open submenus

[dbaron]

This is sort of a side-issue for #1190, but I'd like to spin it into a separate issue because I think it's a separate side discussion.

I think it would be useful for menuitem elements to support the :open pseudo-class. CSS leaves the per-element definitions to be defined by HTML, so I think is something that would end up purely in the HTML spec.

When thinking about :hover-activation behavior for opening submenus in #1190, I noticed that the styling of menuitems on many existing menus is a little bit interesting, but is representable in CSS if menuitems that open submenus support the :open pseudo-class. In particular, typical styling seems to be:

• if a menulist (or menubar??) has a menuitem whose submenu is open, the menuitem for the open submenu is typically highlighted even if hover has moved elsewhere (for example, during the delay or safe triangle that keeps the submenu open while the mouse has moved elsewhere)
• when there is no open submenu, the highlight style follows :hover

Additionally, an open submenu typically still retains some sort of highlight styling when the :hover state has moved into a submenu (although at that point the styling is sometimes different from when the pointer is still in the menu).

I think all of these styles are reasonably representable in CSS (sometimes using selectors like menulist:has(> menuitem:open)) if menuitem elements support :open when they trigger submenus. I think :open is a good name for representing this concept and it already exists in CSS, so I think we should use the existing :open pseudo-class here rather than trying to make a new pseudo-class.

[lukewarlow]

I think menuitem is perhaps the wrong location?

We have it for dialogs and details which are themselves the things that open. But then we have it for select and I think inputs where they control a 'popover' that opens.

To me it feels like menulist would be the thing with :open. (Though as they're a popover we'd maybe get :popover-open on that for free).

If menuitem gets :open should we add it to buttons that control popovers, and/or dialogs? I'm not sure where to draw the line?

[dbaron]

Yeah, I think we already get :popover-open on the menulist. And I think for the reasons above we do need something on the menuitem in order to style it correctly. (It doesn't feel that different from a <select> being open to me, except for the DOM tree structure being different (see #1297 (comment) about non-nested structure.)

[scottaohara]

this would be useful for any item element that reveals another element, matching the 'expanded' state of the invoking element.

i know i definitely mentioned how this would have been good to have for toggling a popover from a button.

[lukewarlow]

So there's this idea we discussed previously. in #622 should we propose exposing :open on command buttons that are in the right states? Essentially matching up with the aria-expanded="true" state?

It'd be hard/impossible to feature detect unfortunately but at least you could use it in future.

Perhaps both of these could be discussed at the joint taskforce meetings to guage how people feel about it.

[scottaohara]

The odd bit there is that :open has been applied to the element that was revealed - so wouldn’t it be weird to reuse it now on the control that revealed the thing now the :open state?

[css-meeting-bot]

The Open UI Community Group just discussed [menu] support :open pseudo-class on <menuitem>s that open submenus, and agreed to the following:

• RESOLVED: we need a pseudo class that indicates that a menuitem triggers a submenu, and that submenu is currently open. TBD on the name.

The full IRC log of that discussion

<keithamus> dbaron: This is closely related to the previous. Menu triggering, submenu opening, one question becomes how to style them.
<keithamus> dbaron: one thing that happens with hover triggering is the safe triangle, where the submenu opens and you can move the mouse so it's not over the sub-menu, but you won't see hover effects for the sub-menu items until you're past the delay or beyond the triangle
<keithamus> dbaron: in terms of styling, having an open submenu tends to behave like forcing a hover state
<keithamus> dbaron: when menus have hover style, typically if the submenu is open the sumenu being open - the item that opened the submenu acts like it's hovered, even if the mouse has moved away
<keithamus> dbaron: so we need a way of styling menu items that are currently opening a submenu
<keithamus> dbaron: if we have that css selectors can take care of the rest
<keithamus> dbaron: but we need to be able to match "this is a menu item that's opened a submenu"
<keithamus> dbaron: we have this class ":open" so html can use that for any open elements
<keithamus> dbaron: there's been some discussion in the issue as to whether that makes sense. Does :open apply to the thing that does the opening or the thing that is open
<lwarlow> q+
<keithamus> dbaron: with select the distinction isn't clear, it's select:open, but for menus these are potentially unrelated things
<keithamus> dbaron: so the question is: do people think it makes sense for :open on the menu item, then you can use :popover-open on the submenu
<masonf> q+
<scott> q+
<keithamus> dbaron: or does :open mean the other thing and we need something different
<keithamus> q+
<keithamus> lwarlow: hesitant, but I've realised :open is slightly inconsistent, reason for that is in part because <select> is composite UI control, didn't expose the picker separately, <input> is the thing that triggers and that gets the pseudo. In that sense <input> is like menu-tiem
<keithamus> lwarlow: on the flip side <dialog>, <details>, :open applies to the thing that's open
<keithamus> lwarlow: for inputs ... other than datalist
<keithamus> lwarlow: I don't think :open applies for datalist right now?
<keithamus> lwarlow: I'm slightly torn on this
<sorvell> q+
<keithamus> lwarlow: if we think open applies to a menu item, then the same is true for a button that has opened a dialog or popover, e.g. command invoker that has expanded=true should have :open
<keithamus> lwarlow: that might be confusing if both are open though
<keithamus> ack lwarlow
<keithamus> dbaron: html spec does in a note say :open should work on inputs with an open datalist.
<keithamus> dbaron: not normative though
<keithamus> dbaron: the other thought is that one thing we've thought about pretty heavily, motivated :popover-open, what constitutes semantics of element vs attributes
<keithamus> dbaron: :open is element semantics, but this is sort-of-element-sort-of-attribute semantics
<keithamus> ack masonf
<keithamus> masonf: wanted to say a lot of what lwarlow says. :open use cases are mixed.
<keithamus> masonf: the only problem I see with that is where you can't disambiguate.
<keithamus> masonf: this is one where it's not ambiguous. The menu item itself can't be a popover, dialog, etc, so it can't be open itself, therefore there's no ambiguity.
<keithamus> masonf: the question is: do I as a developer know what menu-item:open is? It seems very clear
<keithamus> masonf: the alternative is to invent a new special pseudo class just for these case, e.g. :menu-item-with-submenu-open
<lwarlow> Hmm that makes sense, so we have :popover-open because a dialog or details can be open separately to the popover thingy. Whereas that's not true of menuitem
<keithamus> masonf: in which case let's just use this
<keithamus> ack scott
<masonf> qq+
<keithamus> scott: I just lean a bit more towards different. This isn't really just for menu items, we don't have a way to determine a button is in the expanded state, we have a11y states but no way to style based on that.
<keithamus> scott: if we can apply :open to the button as well, sure. I personally wouldn't have done that.
<keithamus> scott: maybe :expanded would have been the way to do it
<keithamus> scott: matches my a11y intuition
<lwarlow> q+
<keithamus> scott: as long as it's not confusing to other developers
<keithamus> scott: not just menu items, but like popover, etc.
<keithamus> masonf: I agree this should probably also apply to command but we should keep those separate issues
<keithamus> masonf: e.g. :open is something in css which we can link to in html
<keithamus> masonf: I do think :expanded makes sense but unfortunately here we are
<keithamus> q-
<masonf> ack mason
<Zakim> masonf, you wanted to react to scott
<keithamus> ack sorvell
<keithamus> sorvell: I am slightly ambivalent about menu-item having :open but when I consider some random dialog that opens a dialog some other place being :open, then that's just weird, which leans me toward it being different.
<keithamus> sorvell: we have a thing thats invoking a command, that think is done, everything's good. But the command implies some state we're not capturing. The thing we're not capturing is the state that's relevant to the invokee
<keithamus> sorvell: somehow, via css, to expose that state to the command - the state of the commanded element to the commandor, so the button can say "hey, based on the state of the target"
<keithamus> sorvell: right now I can make a custom command, with a custom state, i might want that reflected in the thing that can generate that.
<masonf> Like ::target-matches(selector)
<masonf> I guess one : for that, not ::
<keithamus> lwarlow: I don't think adding :expanded now is that weird. Even with :open
<keithamus> lwarlow: I think a dialog is a thing that opens, so it gets :open, details, input (ish)...
<sorvell> q+
<keithamus> lwarlow: but the triggering thing is the command invoker, or the menu-item, they don't match open, if we wanted to introduce expanded then that would be okay
<keithamus> lwarlow: the thing that's open is :open and the thing that expanded it is :expanded
<keithamus> lwarlow: having said that it doesn't solve all the use cases, if you have a custom command with custom state, you probably want to style the button with custom state
<keithamus> lwarlow: play/pause on a media element for example
<keithamus> lwarlow: currently there isn't a nice way to do that, only with all knowledge, no generic selector
<lwarlow> button::commandfor(:open)
<keithamus> lwarlow: if I want to style the button based on the thing that is the commandfor target. We'd get this for free.
<masonf> There's this issue: https://github.com/w3c/csswg-drafts/issues/10970
<keithamus> lwarlow: if we could have that, that would be nice.
<keithamus> lwarlow: probably a can of worms for invalidation. Can't get much worse than has?
<keithamus> lwarlow: you can't trigger the open state based on styling the button
<keithamus> lwarlow: that solves the menu item case. It solves the commandfor generic case.
<keithamus> lwarlow: that's nicer than just the pseudo class
<keithamus> lwarlow: if we do the pseudo class and don't think about the rest later, we'll either not do the rest later or we'll do it and the pseudo class will feel weird.
<masonf> q?
<flackr> q+
<keithamus> sorvell: my preferences in order: 1 explore pseudo element / combinator to connect state. 2. a new name: the reason I don't want the same name - I don't think it should be applied to a button that opens a dialog, the reason is i think you can argue the case of the ambiguity, the select e.g. is a composite control, but menu could be argued it's a
<keithamus> composite control too, but the same cannot be argued for dialog.
<keithamus> sorvell: I think its a problem to treat them the same
<keithamus> sorvell: it's not a case where it's the same thing. I think we have a case where there's a composite control that's doing an action which is clearly part of it
<keithamus> sorvell: sometimes the case with command and sometimes not the case.
<keithamus> ack sorvell
<keithamus> ack dbaron
<Zakim> dbaron, you wanted to talk about commands and menus and magic
<masonf> That argument kind of convinced me. menuitem and command invokers should be two separate issues.
<lwarlow> Actually my earlier point about aria-expanded symetry doesn't always work either because we don't set aria-expanded for buttons controlling modal dialogs (it's not needed). So I'm even more in favour of the combinator.
<keithamus> dbaron: can of worms that might change some opinions: one problem is the way menus are structured, you can reference a menulist as a submenu of more than one menu
<flackr> q-
<keithamus> dbaron: a menulist can be a submenu of your file menu and also your help menu, or something like that.
<keithamus> dbaron: either one of those submenus can be its invoker, and can open it up
<lwarlow> q+
<keithamus> dbaron: if we're talking about some kind of combinator relationship, the relationship has to care about what the invoker is, it cannot purely be a reference to the commandfor
<keithamus> dbaron: it's the commandfor _and_ the invoker
<keithamus> qq+
<keithamus> dbaron: I'm still trying to work out exactly how much of this menu stuff is fully representable as commands, and how much is magical when you call togglemenu showmenu or hidemenu
<keithamus> dbaron: it's unlikely the second set is the empty set.
<keithamus> dbaron: some of these items will have to say "some of these which call showmenu or hidemenu etc then we do these things that make this behave like a submenu"
<keithamus> dbaron: maybe we can somehow describe these as properties of the submenu elements
<keithamus> dbaron: .... that's kind of the point of the submenus is to do something else.
<keithamus> dbaron: some of this stuff makes me a little nervous
<keithamus> dbaron: I dont think we can fully describe using commands
<masonf> q+
<keithamus> dbaron: the combinator needs to care about who the invoker is
<keithamus> dbaron: theres a state about this element invoked the other one
<keithamus> ack keithamus
<Zakim> keithamus, you wanted to react to dbaron
<jarhar> keithamus: anchors are a relationship that is in css that defines these two things
<jarhar> keithamus: i think maybe theres something there
<jarhar> keithamus: anchors do the thing you described where its the commandfor and its also the invoker
<jarhar> q+
<keithamus> lwarlow: I think that probably in most cases if we're styling a menu item or a button, the thing it commands ... you probably want to style it based on the targets state
<keithamus> lwarlow: if you take video, you dont want play pause button to be in the paused state if it wasnt the button that paused it
<keithamus> lwarlow: like the button should represent the targets state. popover-open when open
<keithamus> lwarlow: If command and commandfor aren't the right fit for this, we don't have to use them
<keithamus> lwarlow: if they're more work than necessary
<keithamus> lwarlow: The scope of those is "I do something to that element", the list doesn't need to be small, but we can also just have togglemenu if showmenu/hidemenu are problematic
<keithamus> lwarlow: I see what you mean about the styling as to whether you're the acting invoker or not
<keithamus> lwarlow: if you programatically open the menu list, then associate that, it would use the source as the active thing
<keithamus> lwarlow: that could be something other than a menu item
<keithamus> dbaron: then it's a top level menu rather than a submenu
<sorvell> q+
<keithamus> ack lwarlow
<keithamus> lwarlow: potentially
<jarhar> q-
<keithamus> lwarlow: if it's weird to open a menu from a menu item is it weird to open a .... ?
<keithamus> lwarlow: can it just be a one off button?
<keithamus> lwarlow: if it's weird for menu item it might be weird for button, is that accounted for?
<keithamus> masonf: a hamburger is a single button that opens a menu, and I can see that looking different when the menu is open, so there's a use case
<keithamus> masonf: a much more complicated question about command invokers and combinators in between, those are great questions, but even in a world where that exists there's still a common use case here
<lwarlow> q+
<keithamus> masonf: in that world it's okay to have two ways to do something: easy way with :expanded and the more complicated way with combinators e.g.
<keithamus> masonf: command invokers also do stateless things like step up and step down, how do they work?
<keithamus> masonf: I'd love to separate that
<keithamus> ack sorvell
<keithamus> sorvell: the connection combinator seems worthwhile but complicated, maybe we could punt that... but can we take advantage of the fact that this is always an anchor?
<keithamus> sorvell: is there a way with css anchorpos to say "I am the element that has been anchored to"
<keithamus> sorvell: if there isn't, maybe we add that?
<keithamus> lwarlow: I think :open is probably okay but we need to discuss this in the joint task force to see what others think
<keithamus> lwarlow: I will be there to point out the button
<keithamus> lwarlow: I think for what this is doing :open is probably okay.
<masonf> Proposed resolution: we need a pseudo class that indicates that a menuitem triggers a submenu, and that submenu is currently open. TBD on the name.
<keithamus> dbaron: it sounds like we dont have a firm conclusion, and we need to discuss more in the task force.
<lwarlow> +1
<keithamus> +1
<jarhar> +1
<dbaron> +1
<sorvell> +1
<masonf> RESOLVED: we need a pseudo class that indicates that a menuitem triggers a submenu, and that submenu is currently open. TBD on the name.
<keithamus> Zakim, please leave
<Zakim> leaving. As of this point the attendees have been masonf, flackr, bkardell, lwarlow
<keithamus> RRSAgent, make minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2026/01/22-openui-minutes.html keithamus

[css-meeting-bot]

The CSS Working Group just discussed [menu] support :open pseudo-class on <menuitem>s that open submenus, and agreed to the following:

• RESOLVED: :open matches a menuitem that triggers a submenu, and that submenu is currently open (confirm with all vendors)

The full IRC log of that discussion

<jarhar> dbaron: whatever we decide here should apply to application menus and navigation menus
<jarhar> dbaron: there is a need to style a menu item depending on whether its submenu is open, and we need to decide a pseudo class for this
<jarhar> dbaron: we could reuse :open
<jarhar> dbaron: it isnt clear whether :open currently applies to things that open stuff or the thing itself that is opened
<jarhar> q+
<jarhar> dbaron: in openui, a bunch of us thought that :open was fine, and others thought that reusing :open would be weird on the thing that does the opening
<lwarlow> q+
<jarhar> jarhar: some might think that the menulist should match :open instead of :popover-open
<cwilso> ack next
<cwilso> ack next
<masonf> q+
<jarhar> lwarlow: im not one way or the other right now. currently :open applies in both situations. in details and dialog its the thing that opens. in select its both. for input its kind of the thing that does the opening and kind of the picker
<jarhar> lwarlow: not sure if it applies for datalist
<jarhar> lwarlow: i think menulist matching :popover-open is a consequence of it being a popover
<jarhar> lwarlow: we dont have to add the popover attribute, but its a popover
<jarhar> lwarlow: i dont think menulist will be the only element that will be a popover
<dbaron> s/be a popover/be an implicit popover/
<jarhar> lwarlow: we could add the automatic popoverness to elementinternals
<jarhar> lwarlow: menulist matching :popover-open is fine
<jarhar> lwarlow: my main holdup is if we say that menutiem should match :open then that implies that command invokers should match :open when they have a popover that is open
<jarhar> lwarlow: the relationship there is very similar
<jarhar> lwarlow: if we dont like that, then some sort of :expanded pseudo class
<masonf> q-
<jarhar> lwarlow: we already have :open for many cases that match aria-expanded
<cwilso> ack next
<jarhar> masonf: im afraid of the command invokers because thats a whole can of worms
<jarhar> masonf: :open makes sense because theres no ambiguity
<jarhar> masonf: menuitem is not a thing itself that can be opened
<jarhar> masonf: if you put :open on a menuitem its easy to understand
<jarhar> masonf: im in favor of that resolution
<jarhar> smaug: im looking at xul implementation of menu. david do you remember whats done there? maybe we dont have anything specific for this, could have been done on js side
<jarhar> smaug: the behavior is there
<jarhar> dbaron: i dont remember. my intuition is that xul menus have a different tree structure
<jarhar> dbaron: might not be remembering that correctly
<jarhar> smaug: openui proposal was very similar to xul, but i havent looked at latest
<jarhar> masonf: by tree structure, it has nesting?
<jarhar> dbaron: yes
<jarhar> smaug: in some examples they were doing that
<lwarlow> I could +1 a resolution to use :open but I do think it's worth checking with Apple too.
<dbaron> https://searchfox.org/firefox-main/source/browser/base/content/browser-menubar.inc
<lwarlow> PROPOSED RESOLUTION: menuitems use :open (Confirm with all vendors)
<masonf> Proposed resolution: :open matches a menuitem that triggers a submenu, and that submenu is currently open
<jarhar> proposed resolution: use :open on menuitems while their submenu is open
<masonf> ahh
<masonf> Proposed resolution: :open matches a menuitem that triggers a submenu, and that submenu is currently open (confirm with all vendors)
<cwilso> +1
<masonf> +1
<lwarlow> +1
<jarhar> +1
<dbaron> +1
<cwilso> RESOLVED: :open matches a menuitem that triggers a submenu, and that submenu is currently open (confirm with all vendors)