You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[css-ui] Add or reuse pseudo-element for openable-submenu indicator (triangle) #13430
We're doing work to add elements to HTML that represent menus (see explainer and PR). The initial work is for application menus, though we hope to follow that with similar work covering navigation menus, which would probably reuse many aspects of the design (including this choice of pseudo-element).
One issue we have is how to style the marker that indicates that a menu item opens a submenu. This is typically a triangular marker at the right side, such as the one next to "Zoom" in this screenshot from the explainer:
I think there are a few different options for how to style this, and we should choose one. The main options I see are:
Use ::after.
Pro: Matches the way a developer would typically have built this themselves if it weren't a platform feature.
Con: Uses something that maybe should be left for web developers to use rather than being part of a platform feature.
Use ::marker.
Pro: Matches what we do for <details>/<summary> which is styled as a list-item and thus has a similar expansion triangle (although at the inline-start edge).
Con: Basically all other uses of ::marker show up at the beginning rather than the end (for list items and for <details>/<summary>)
The CSS Working Group just discussed [css-ui] Add or reuse pseudo-element for openable-submenu indicator (triangle), and agreed to the following:
RESOLVED: Mint a new pseudo-element for this, name TBD. It comes after ::after.
The full IRC log of that discussion
<lwarlow> q+
<jarhar> dbaron: menuitems which open submenus usually have arrows next to them to indicate that they open a submenu
<masonf> ::submenu-arrow-thingy
<masonf> q+
<astearns> slight preference for *not* overloading ::after
<cwilso> +1
<jarhar> dbaron: we can use ::after, ::picker-icon, ::marker, or create a new pseudo element
<cwilso> ack next
<jarhar> lwarlow: i am quite keen that we reserve before and after for author space
<jarhar> lwarlow: using a browser provided pseudo is probably for the best
<jarhar> lwarlow: author might want to use before/after in addition to this
<jarhar> lwarlow: it should come after ::after like picker-icon does
<jarhar> lwarlow: two things worth keeping in mind here. some menuitems will have a checkmark pseudo which comes in the front
<jarhar> lwarlow: its not uncommon for menuitems to have keyboard shortcuts and to display those shortcuts in the ui
<jarhar> lwarlow: if the author wanted to do that they could put it in the ::after pseudo element
<jarhar> lwarlow: if we use ::after we're conflicting with that
<jarhar> lwarlow: picker-icon works
<jarhar> lwarlow: the thing that its not an icon is dubious. what is an icon? if its an icon for select then its an icon for this. but yeah its not a picker
<jarhar> lwarlow: picker-icon or make a new pseudo element
<jarhar> lwarlow: were making new ones for css forms anyway
<jarhar> lwarlow: i think make a new pseudo and put it after ::after, then we can come up with a name. should probably include "icon" in its name
<cwilso> ack next
<jarhar> masonf: +1 to everything luke just said. my point about picker-icon wasnt necessarily the name
<jarhar> masonf: mostly that we had this exact conversation for customizable select with the same list of options
<jarhar> masonf: we went from ::after, then to ::marker
<jarhar> masonf: we ended at ::picker-icon, and it comes after ::after
<jarhar> masonf: we should follow that but with a new name
<jarhar> +1
<lwarlow> Oh also marker is limited styleability too. So we just should leave that behind imo.
<masonf> haha
<dbaron> (we should probably also make ::picker-icon work for datetime inputs)
<lwarlow> ::submenu-icon
<jarhar> smaug: i cant immediatly come up with an obvious name for this
<masonf> ::submenu-indicator
<masonf> Proposed resolution: a new pseudo element, which comes after ::after
<lwarlow> PROPOSED RESOLUTION: Mint a new pseudo-element for this, name TBD
<dbaron> cwilso: should straw poll for names
<lwarlow> Proposed resolution: Mint a new pseudo-element for this, name TBD. It comes after ::after.
<cwilso> +1
<lwarlow> +1
<dbaron> +1
<masonf> +1
<cwilso> RESOLVED: Mint a new pseudo-element for this, name TBD. It comes after ::after.
In old drafts of css-ui, there was display: icon which fits this situation conceptually because the submenu is displayed as only a triangle icon until it gets revealed fully – except that this icon stays visible then!
Anyway, the important design question this raises is: Do you consider this pseudo-element to be a part of the parent (menu entry) or of the child (submenu block)?
If the latter, I would say ::marker was sufficient.
If you really must introduce yet another pseudo-element for the former, a handful of relevant terms to inspire bikeshedding are: chevron, nest, reveal, fold, expand, cascade.
Please note, that keyboard shortcuts are often shown in the same place as this indicator, although I’d say they belong in ::after.
This is associated with the menuitem, not the submenu. It has to show when the submenu is not visible, so that the user knows that the item opens a submenu. (Also note that there is not a parent-child relationship between the menuitem and the submenu that it invokes.)
We're currently using ::reveal-icon in css-forms for something unrelated (password reveal), and ::picker-icon for a related concept (opening a select menu). Maybe we could re-use ::picker-icon?
In any case, I think we should continue with the -icon pattern, so ::expand-icon is maybe better than ::expand-arrow.
I think the -arrow suffix is a misnomer. The default isn't even going to be an arrow it'll be a triangle (like details and select), in some designs it might be a chevron, in other perhaps a dot. The point being it could be any kind of icon so arrow feels wrong.
Then again we currently have ::checkmark for checkbox but also radio so the the name being the wrong shape isn't necessarily a deal breaker.
Given we already use -icon I think that's better though.
The CSS Working Group just discussed [css-ui] Add or reuse pseudo-element for openable-submenu indicator (triangle), and agreed to the following:
RESOLVED: ::expand-icon
The full IRC log of that discussion
<jarhar> astearns: it seemed to me that we agreed on icon, but maybe im wrong
<jarhar> astearns: lets try to decide on a name if we can
<jarhar> dbaron: weve had some discussion in the issue. my initial summary was that probably we want a two part name, where the first part if a verb and the second part is a noun
<jarhar> dbaron: the first part might not be a verb, it could be submenu or reveal or expand
<jarhar> dbaron: second part would be icon or marker or arrow
<jarhar> dbaron: most people want an A-B name in that space, and what values we want
<jarhar> dbaron: it sounds like people were reasonably happy with expand-icon
<jarhar> dbaron: expand fits with aria expanded state that exists already
<jarhar> dbaron: icon fits with picker-icon
<jarhar> dbaron: id be happy to resolve on expand-icon
<jarhar> +1
<jarhar> test
<jarhar> proposed resolution: ::expand-icon
<lwarlow> +1
<jarhar> RESOLVED: ::expand-icon
Activity
dbaron commentedon Feb 3, 2026
@mfreed7 points out that this is also somewhat similar to
::picker-icon, except that this isn't a picker and it isn't really an icon.lukewarlow commentedon Feb 5, 2026
I feel like this is closer to
::picker-iconthan it is::markerbut that's not to say I couldn't be persuaded.But we should do a new one imo.
css-meeting-bot commentedon Feb 5, 2026
The CSS Working Group just discussed
[css-ui] Add or reuse pseudo-element for openable-submenu indicator (triangle), and agreed to the following:RESOLVED: Mint a new pseudo-element for this, name TBD. It comes after ::after.The full IRC log of that discussion
<lwarlow> q+<jarhar> dbaron: menuitems which open submenus usually have arrows next to them to indicate that they open a submenu
<masonf> ::submenu-arrow-thingy
<masonf> q+
<astearns> slight preference for *not* overloading ::after
<cwilso> +1
<jarhar> dbaron: we can use ::after, ::picker-icon, ::marker, or create a new pseudo element
<cwilso> ack next
<jarhar> lwarlow: i am quite keen that we reserve before and after for author space
<jarhar> lwarlow: using a browser provided pseudo is probably for the best
<jarhar> lwarlow: author might want to use before/after in addition to this
<jarhar> lwarlow: it should come after ::after like picker-icon does
<jarhar> lwarlow: two things worth keeping in mind here. some menuitems will have a checkmark pseudo which comes in the front
<jarhar> lwarlow: its not uncommon for menuitems to have keyboard shortcuts and to display those shortcuts in the ui
<jarhar> lwarlow: if the author wanted to do that they could put it in the ::after pseudo element
<jarhar> lwarlow: if we use ::after we're conflicting with that
<jarhar> lwarlow: picker-icon works
<jarhar> lwarlow: the thing that its not an icon is dubious. what is an icon? if its an icon for select then its an icon for this. but yeah its not a picker
<jarhar> lwarlow: picker-icon or make a new pseudo element
<jarhar> lwarlow: were making new ones for css forms anyway
<jarhar> lwarlow: i think make a new pseudo and put it after ::after, then we can come up with a name. should probably include "icon" in its name
<cwilso> ack next
<jarhar> masonf: +1 to everything luke just said. my point about picker-icon wasnt necessarily the name
<jarhar> masonf: mostly that we had this exact conversation for customizable select with the same list of options
<jarhar> masonf: we went from ::after, then to ::marker
<jarhar> masonf: we ended at ::picker-icon, and it comes after ::after
<jarhar> masonf: we should follow that but with a new name
<jarhar> +1
<lwarlow> Oh also marker is limited styleability too. So we just should leave that behind imo.
<masonf> haha
<dbaron> (we should probably also make ::picker-icon work for datetime inputs)
<lwarlow> ::submenu-icon
<jarhar> smaug: i cant immediatly come up with an obvious name for this
<masonf> ::submenu-indicator
<masonf> Proposed resolution: a new pseudo element, which comes after ::after
<lwarlow> PROPOSED RESOLUTION: Mint a new pseudo-element for this, name TBD
<dbaron> cwilso: should straw poll for names
<lwarlow> Proposed resolution: Mint a new pseudo-element for this, name TBD. It comes after ::after.
<cwilso> +1
<lwarlow> +1
<dbaron> +1
<masonf> +1
<cwilso> RESOLVED: Mint a new pseudo-element for this, name TBD. It comes after ::after.
dbaron commentedon Feb 5, 2026
I think a bunch of possible names take the form
::A-Bwhere:Acan besubmenuorreveal[Edit: orexpand]Bcan beicon,indicator,marker, orarrowI'm curious if others have opinions within that space of 8 names, or other options (either additional A or B variants, or other options entirely).
Crissov commentedon Feb 5, 2026
In old drafts of css-ui, there was
display: iconwhich fits this situation conceptually because the submenu is displayed as only a triangle icon until it gets revealed fully – except that this icon stays visible then!Anyway, the important design question this raises is: Do you consider this pseudo-element to be a part of the parent (menu entry) or of the child (submenu block)?
If the latter, I would say
::markerwas sufficient.If you really must introduce yet another pseudo-element for the former, a handful of relevant terms to inspire bikeshedding are: chevron, nest, reveal, fold, expand, cascade.
Please note, that keyboard shortcuts are often shown in the same place as this indicator, although I’d say they belong in
::after.dbaron commentedon Feb 5, 2026
This is associated with the menuitem, not the submenu. It has to show when the submenu is not visible, so that the user knows that the item opens a submenu. (Also note that there is not a parent-child relationship between the menuitem and the submenu that it invokes.)
dbaron commentedon Feb 17, 2026
Some notes about existing names for this. Based on the list in https://open-ui.org/components/menu.research/ I found:
expandIconas part of its API surfaceutility:chevronrighticon for submenus to make the indicator show up!We could use the name "chevron" given that precedent, but I think maybe "arrow" is clearer?
Out of the options in #13430 (comment) I think my preference would probably be one of
::submenu-iconor::expand-arrowor::reveal-arrow.fantasai commentedon Feb 17, 2026
We're currently using
::reveal-iconin css-forms for something unrelated (password reveal), and::picker-iconfor a related concept (opening a select menu). Maybe we could re-use::picker-icon?In any case, I think we should continue with the
-iconpattern, so::expand-iconis maybe better than::expand-arrow.lukewarlow commentedon Feb 18, 2026
I think the -arrow suffix is a misnomer. The default isn't even going to be an arrow it'll be a triangle (like details and select), in some designs it might be a chevron, in other perhaps a dot. The point being it could be any kind of icon so arrow feels wrong.
Then again we currently have ::checkmark for checkbox but also radio so the the name being the wrong shape isn't necessarily a deal breaker.
Given we already use -icon I think that's better though.
css-meeting-bot commentedon Feb 19, 2026
The CSS Working Group just discussed
[css-ui] Add or reuse pseudo-element for openable-submenu indicator (triangle), and agreed to the following:RESOLVED: ::expand-iconThe full IRC log of that discussion
<jarhar> astearns: it seemed to me that we agreed on icon, but maybe im wrong<jarhar> astearns: lets try to decide on a name if we can
<jarhar> dbaron: weve had some discussion in the issue. my initial summary was that probably we want a two part name, where the first part if a verb and the second part is a noun
<jarhar> dbaron: the first part might not be a verb, it could be submenu or reveal or expand
<jarhar> dbaron: second part would be icon or marker or arrow
<jarhar> dbaron: most people want an A-B name in that space, and what values we want
<jarhar> dbaron: it sounds like people were reasonably happy with expand-icon
<jarhar> dbaron: expand fits with aria expanded state that exists already
<jarhar> dbaron: icon fits with picker-icon
<jarhar> dbaron: id be happy to resolve on expand-icon
<jarhar> +1
<jarhar> test
<jarhar> proposed resolution: ::expand-icon
<lwarlow> +1
<jarhar> RESOLVED: ::expand-icon
Implement ::expand-icon pseudo-element
Implement ::expand-icon pseudo-element
Implement ::expand-icon pseudo-element
Implement ::expand-icon pseudo-element
Bug 2024608 [wpt PR 58602] - Implement ::expand-icon pseudo-element, …
Bug 2024608 [wpt PR 58602] - Implement ::expand-icon pseudo-element, …