[css-ui] Add or reuse pseudo-element for openable-submenu indicator (triangle)

[dbaron]

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:

1. 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.
2. 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>)
3. Create a new pseudo-element.
   • Pro: Matches what we did for option::checkmark (see [css-ui] UA stylesheet for appearance:base <select> #10857 and [css-ui] Pseudo-elements for checkmark and dropdown icon for appearance:base <select> #10908).
   • Con: Yet another pseudo-element.

[dbaron]

@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]

I feel like this is closer to ::picker-icon than it is ::marker but that's not to say I couldn't be persuaded.

But we should do a new one imo.

[css-meeting-bot]

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]

I think a bunch of possible names take the form ::A-B where:

• A can be submenu or reveal [Edit: or expand]
• B can be icon, indicator, marker, or arrow

I'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]

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.

[dbaron]

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]

Some notes about existing names for this. Based on the list in https://open-ui.org/components/menu.research/ I found:

• https://ant.design/components/menu has expandIcon as part of its API surface
• https://spectrum.adobe.com/page/menu/ calls this a chevron but doesn't have API for it
• https://www.lightningdesignsystem.com/2e1ef8501/p/40f658-menu requires that the user explicitly add a utility:chevronright icon 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-icon or ::expand-arrow or ::reveal-arrow.

[fantasai]

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.