[selectmenu] Method to change arrow icon?

[hidde]

In our design system / authoring tool, we have a selectmenu-like component that uses a custom arrow:

When I tried to recreate it with <selectmenu>, I got the default <selectmenu> arrow.

I was able to insert my own arrow by creating a custom button (see linked Codepen below), but it would be nice to do it with the default button.

Could we add a way to change the arrow icon without replacing the entire button (maybe with ::marker?)?

Related Codepens:

• Example with my own custom button
• Example with just a standard selectmenu and options

[captainbrosset]

I agree that this would be useful. I wrote several demos with the selectmenu component, and for some of them I only wanted a custom icon. Having to replace the entire button part for this seems a bit much.

[chrisdholt]

We added a slot for the icon as well with FAST's select as well for this common use case. I'd love to see either ::marker or a slot unique to this to support the simple scenario.

[mfreed7]

I’m going to miss the meeting today, but I wanted to register my support for this proposal. It would seem to make the most sense to just add a slot for the icon, akin to the other two slots we already have.

[css-meeting-bot]

The Open UI Community Group just discussed selectmenu] Method to change arrow icon?.

The full IRC log of that discussion

<gregwhitworth> Topic: selectmenu] Method to change arrow icon?
<hdv> github: https://github.com//issues/548
<gregwhitworth> scribenick: gregwhitworth
<gregwhitworth> hdv: I tried to build a select that we have, so this issue is to allow a method to change the arrow
<scotto> q+
<gregwhitworth> hdv: another suggestion if a slot, but we also have `::marker`
<dandclark> q+
<gregwhitworth> hdv: mason liked adding a slot
<gregwhitworth> ack scotto
<hdv> scotto: seems like something a slot would be useful for
<gregwhitworth> scotto: yeah it seems that a slot would be useful for, please don't make it a marker - details summary is why we don't want this
<gregwhitworth> scotto: I'm going to lose my mind
<gregwhitworth> scotto: using the marker element it gets included in the accessible name
<gregwhitworth> ack dandclark
<gregwhitworth> dandclark: I'm wanting to simplify the selectmenu and a slot element makes the most sense
<gregwhitworth> dandclark: do we see other examples of this? Chris Holt said that FAST does this
<gregwhitworth> q+
<hdv> gregwhitworth: if you actually look at the standard select across browsers you'll notice a slight difference in arrows
<hdv> gregwhitworth: seems to be slot would be ideal as the other stuff is also done via slots
<gregwhitworth> ack gregwhitworth
<dandclark> Proposed resolution: <selectmenu>'s shadow DOM has a <slot> around the button's default arrow icon so that the icon can be replaced by authors without replacing the entire button.
<gregwhitworth> dandclark: we may not want to use the term part
<gregwhitworth> dandclark: we're not saying that
<hdv> q+
<JonathanNeal> q+
<gregwhitworth> dandclark: we're not giving it any special magic
<gregwhitworth> ack hdv
<gregwhitworth> hdv: does that mean we won't be able to replace it with CSS?
<gregwhitworth> dandclark: you wouldn't be able to just change it with CSS, you would use content and then assign it to the slot via the slot attribute
<gregwhitworth> dandclark: that would allow your CSS to then target that
<gregwhitworth> hdv: as a dev, I would probably reach for CSS first
<masonf> The new icon would be a child of the <selectmenu>: <selectmenu><img slot=icon src=foo></selectmenu>
<gregwhitworth> hdv: it does make sense that it would happen in HTML
<gregwhitworth> hdv: I guess it depends on the usecase, but I usually will reach for CSS
<gregwhitworth> q+
<gregwhitworth> ack JonathanNeal
<gregwhitworth> JonathanNeal: I wanted clarification for the part indicator
<gregwhitworth> JonathanNeal: is that our general opinion or conformance that we should mind?
<hdv> gregwhitworth: is the issue with using ::part our opinion or is this something for conformance that we should mind?
<hdv> s/gregwhitworth/JonathanNeal
<masonf> I thought we were already planning to expose (as ::part()s) the other slotted content, like ::part(button)?
<hdv> dandclark: the parts have special behaviors applied by the platform
<hdv> dandclark: there is also the part concept in CSS, there is a naming collission there
<hdv> dandclark: I think we don't want to do that with the dropdown arrow icon
<gregwhitworth> q?
<masonf> We
<masonf> We're already exposing the button and listbox as ::part() right?
<chrishtr> +1 to exposing via css
<masonf> Why not this one?
<JonathanNeal> +1 to exposing via css
<hdv> dandclark: to mason, yes we and we could do that too
<hdv> s/yes we/yes we are,
<hdv> gregwhitworth: the reason we went for parts is teaching people about web components
<tantek> hdv++ I too would reach for CSS first. I also understand a more uniform model if the group has decided on parts for everything like that.
<tantek> +1 to exposing via css
<hdv> gregwhitworth: seems like we could make it available as part as well
<hdv> gregwhitworth: ultimately the thing you want to reach for is a slot, because that really gives full control
<hdv> gregwhitworth: but some will want to do it via CSS, so having both would be best of both worlds
<JonathanNeal> we got color, background color, border color, accent color, caret color, colors that climb on rocks.
<tantek> q+ to note I'd be interested in what use-cases are being addressed with a "part" that aren't addressed by existing CSS (on a pseudo-element)
<hdv> gregwhitworth: what would be your thoughts on that dandclark ?
<gregwhitworth> ack gregwhitworth
<hdv> dandclark: would help with that shared stylesheet… in Chrome it is implemented via SVG, it would be different if somebody would use an image
<hdv> gregwhitworth: right, it would have to be standardised
<gregwhitworth> ack tantek
<Zakim> tantek, you wanted to note I'd be interested in what use-cases are being addressed with a "part" that aren't addressed by existing CSS (on a pseudo-element)
<hdv> tantek: it sounds to me that you have experience with use cases, that would require more than CSS would give control over
<gregwhitworth> q+
<hdv> tantek: the reason I'm asking… not because I feel it should be one or the other… but more to make it easier to convey to developers, we could say if you have a simpler use case 'you could just use CSS for that', if you have a fancier use case, you would replace the slot
<hdv> q+
<hdv> gregwhitworth: I agree… once we have the styles we can show that.
<tantek> also, the advantage of "just using CSS for it" is that you avoid LOTS of accessibility pitfalls
<hdv> gregwhitworth: one of the use cases for having not just a pseudo but actual replacement is when people have more use cases like fancier animations
<masonf> <video> for the arrow
<una> q+
<gregwhitworth> ack gregwhitworth
<gregwhitworth> ack hdv
<gregwhitworth> hdv: +1 to tantek's point
<gregwhitworth> hdv: I did a lightning talk on this and devs were really responsive to it
<una> q-
<masonf> +1
<hdv> una: I also wanted to +1. One of the biggest use cases for styling the icon is resizing it… you can do that with CSS. border radius, color, etc, those seem like the majority of use cases to me too
<dandclark> Proposed resolution: <selectmenu>'s shadow DOM has a <slot> around the button's default arrow icon so that the icon can be replaced by authors without replacing the entire button. The icon will also be exposed as a CSS `::part()`.
<JonathanNeal> +1
<masonf> +1
<hdv> +1
<andrico1234> +1
<AlexanderFutekov> +1
<dandclark> Resolved: <selectmenu>'s shadow DOM has a <slot> around the button's default arrow icon so that the icon can be replaced by authors without replacing the entire button. The icon will also be exposed as a CSS `::part()`.
<JonathanNeal> Now I’m gonna make a ‘character selection’ drop-down, which, depending on the actively selected character option, it’ll change the indicator to that character holding the indicator. :D
<masonf> Do you need all-caps on RESOLVED?

[gregwhitworth]

For ease of finding it in the minutes, the resolution was:

Resolved: 's shadow DOM has a around the button's default arrow icon so that the icon can be replaced by authors without replacing the entire button. The icon will also be exposed as a CSS ::part().

[dandclark]

Markdown ate the elements in the above copy/paste from the minutes; here's the resolution with those included:

Resolved: <selectmenu>'s shadow DOM has a <slot> around the button's default arrow icon so that the icon can be replaced by authors without replacing the entire button. The icon will also be exposed as a CSS ::part().

[dandclark]

I'm going to close this since we had a clear resolution. I filed https://bugs.chromium.org/p/chromium/issues/detail?id=1357866 to update the Chromium prototype.

[dandclark]

Reopening because I just realized we never decided what the name of the slot should be. Maybe button-icon? Or dropdown-icon, arrow-icon, just icon?

[chrisdholt]

Reopening because I just realized we never decided what the name of the slot should be. Maybe button-icon? Or dropdown-icon, arrow-icon, just icon?

Unless there are multiple icons specifically within the anatomy I'd probably prefer to avoid unnecessarily prefixing if we don't have to.

[mahi072]

Hi @hidde, I would like to contribute in this issue if its still open.
Please guide me through this

[css-meeting-bot]

The Open UI Community Group just discussed Method to change arrow icon?, and agreed to the following:

• RESOLVED: The slot around the selectmenu's button's icon is named "marker". The marker will also be addressible via a `part=marker` attribute.

The full IRC log of that discussion

<gregwhitworth> Topic: Method to change arrow icon?
<gregwhitworth> github: https://github.com//issues/548
<hdv> dandclark: we previously resolved to add a slot around the selectmenu's icon to that it can be styled without replacing whole element, but we forgot to name it
<masonf> q+
<hdv> dandclark: do we want to call it 'icon', as we probably don't have other icons
<gregwhitworth> ack masonf
<hdv> q+
<hdv> masonf: are we sure there will only ever be icon? if so I vote icon
<AlexanderFutekov_> q+
<hdv> scotto_: I'd definitely like this to be icon than button because that might make people think they can put anything in there
<hdv> scottkelum: can we use 'marker'?
<hdv> masonf: hm yea tthey look similar
<gregwhitworth> ack hdv
<gregwhitworth> hdv: I was going to ask what the other suggestions were, was it button-icon?
<gregwhitworth> hdv: my thought is for icon as well
<masonf> +1 to marker also. My vote is really just avoiding "button-" or "dropdown-".
<JonathanNeal> q+
<gregwhitworth> ack AlexanderFutekov_
<scotto_> q+
<hdv> AlexanderFutekov_: I was also going to suggest using marker, because we already use it for pseudo elements in details/summary, just rings a bell
<gregwhitworth> ack JonathanNeal
<hdv> JonathanNeal: does anyone here know why the name marker was chosen? is it a liberal enough word to apply to both of these?
<hdv> gregwhitworth: dbaron where you there by chance?
<hdv> dbaron: marker predates me by quite a bit \
<gregwhitworth> ack scotto_
<JonathanNeal> +1 to marker, then.
<hdv> bkardell_: looks like tantek edited that
<hdv> s/that/that spec
<gregwhitworth> q+
<hdv> scotto_: the marker for detail/summary is included inside of the summary element… using CSS pseudos it will be included as part of the accessible name, which i've been trying to file issues for
<hdv> scotto_: details/summary is a pretty quirky element
<hdv> gregwhitworth: my only feedback is… will it make people think this will use the marker pseudo
<hdv> masonf: maybe they should be allowed to?
<JonathanNeal> q+
<bkardell_> best note of the day: https://www.w3.org/TR/2002/WD-css3-lists-20020220/#markers
<gregwhitworth> ack gregwhitworth
<hdv> gregwhitworth: but then we add complexity for naming consistency
<gregwhitworth> ack JonathanNeal
<bkardell_> "The name ::marker is temporary. We need a better name. At the moment the word 'marker' is seriously overloaded. XXX"
<hdv> JonathanNeal: I thought :: being a pseudo element meant it came before Shadow DOM… I thought it did refer to a real element… but unlike the old marker you actually have access to this element
<bkardell_> (2002)
<hdv> gregwhitworth: yes kind of what I was raising, you would do `::part(marker)`
<hdv> q+
<gregwhitworth> ack hdv
<bkardell_> be careful of your temporary names, they can become permanant :)
<JonathanNeal> I would think `::marker` and `::part(marker)` are synonymous?
<gregwhitworth> hdv: when I filed this issue I thought of ::marker and there was a reason we didn't but I don't recall what it was
<hdv> gregwhitworth: so it seems people aren't thrilled with `button-icon` so seems to be between `icon` and `marker`
<JonathanNeal> B
<masonf> B: marker
<AlexanderFutekov> B
<bkardell_> abstain
<hdv> B - not strongly at all, also fine with A
<hdv> gregwhitworth: A is icon, B is marker
<dandclark> abstain, I'm undecided.
<sarah_h> abstain
<scotto_> icon-marker
<masonf> For me, mostly just *not* button-* or dropdown-*.
<hdv> scotto_: I am joking
<JonathanNeal> `::part-marker` :P
<hdv> gregwhitworth: so the resolution will be that the slot will be marker
<dbaron> abstain
<sarah_h> marker, but using an emoji of a marker: 🖊️
<dandclark> Proposed resolution: The slot around the selectmenu's button's icon is named "icon".
<hdv> s/slot will be/slot will be named
<hdv> gregwhitworth: hm… not everybody wants to change the graphic, they may want to remove it…
<JonathanNeal> I am fine with the parity between the slot and the part. The part refers to the shadow, the slot refers to what gets slotted inside the part?
<hdv> gregwhitworth: ironically I did get a tweet yesterday from someone asking to move the marker a few pixels
<dandclark> Proposed resolution, corrected: The slot around the selectmenu's button's icon is named "marker".
<hdv> gregwhitworth: I don't think it always has to be controller code that controls these styles
<hdv> masonf: isn't the controller code set by behavior?
<hdv> masonf: we won't add behavior for this one
<hdv> gregwhitworth: so can we resolve to having a slot and a part?
<hdv> dandclark: I'm not opposed
<dandclark> Proposed resolution: The slot around the selectmenu's button's icon is named "marker". The icon itself has the `part` attribute.
<JonathanNeal> +1
<hdv> masonf: I think it's currently implemented on the slots, not sure what you'd do otherwise?
<hdv> dandclark: if you use the default content it is just one element, the button
<hdv> masonf: you think we apply the part directly to the content?
<hdv> dandclark: I think we do
<dandclark> Proposed resolution: The slot around the selectmenu's button's icon is named "marker". The marker will also be addressible via a `part=marker` attribute.
<JonathanNeal> +1
<AlexanderFutekov> +1
<gregwhitworth> hdv: what does part=marker mean?
<gregwhitworth> selectmenu::part('marker') { margin: 5px; }
<dandclark> RESOLVED: The slot around the selectmenu's button's icon is named "marker". The marker will also be addressible via a `part=marker` attribute.
<hdv> masonf: to confirm: Dan is right, this might need some technical investigation to see if it can technically be done

[hidde]

@dandclark I see in the editor's draft and the how to use the 'marker' part is not included, do we want it updated and could I potentially help with that?

[josepharhar]

We resolved to add a slot/part for this and to name it marker, and it has been implemented in the chromium prototype, so I am going to close this issue