selectlist: customizing the default button's marker is weird

[josepharhar]

I was just trying to change the color of the marker in the selectlist's default button, which can be accessed via ::marker - although I haven't implemented this in the chromium prototype yet, so for now its still ::part(marker).

Setting color or content didn't seem to do anything. I even removed the background-image property to get rid of the svg that we currently render in there, but that didn't make the content start showing...

This would have been easier to do when we had a slot for the marker to replace it with whatever you want, but if you really want to customize the default marker then you're better of just using your own <button type=selectlist>.

Should we encourage people to make their own <button type=selectlist> in order to customize the marker and consider getting rid of ::marker entirely if it isn't useful? Or should we make ::marker easier to use, perhaps by changing the user-agent styles? I don't feel like it's important enough to make a new <marker> element to bring us up to par with the slot we used to have, but maybe it is...

Here are the styles that we currently have in the marker in the chromium prototype:

selectlist::-internal-selectlist-button-icon {
    background-image: -internal-light-dark(url(data:image/svg+xml;base64,PHN2ZyB3aWR0aD0iMjAiIGhlaWdodD0iMTQiIHZpZXdCb3g9IjAgMCAyMCAxNiIgZmlsbD0ibm9uZSIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj5cCiAgPHBhdGggZD0iTTQgNiBMMTAgMTIgTCAxNiA2IiBzdHJva2U9IldpbmRvd1RleHQiIHN0cm9rZS13aWR0aD0iMyIgc3Ryb2tlLWxpbmVqb2luPSJyb3VuZCIvPlwKPC9zdmc+), url(data:image/svg+xml;base64,PHN2ZyB3aWR0aD0iMjAiIGhlaWdodD0iMTQiIHZpZXdCb3g9IjAgMCAyMCAxNiIgZmlsbD0ibm9uZSIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj5cCiAgPHBhdGggZD0iTTQgNiBMMTAgMTIgTCAxNiA2IiBzdHJva2U9IiNmZmZmZmYiIHN0cm9rZS13aWR0aD0iMyIgc3Ryb2tlLWxpbmVqb2luPSJyb3VuZCIvPlwKPC9zdmc+));
    background-origin: content-box;
    background-size: contain;
    height: 1em;
    margin-inline-start: 4px;
    opacity: 1;
    padding-bottom: 2px;
    padding-inline-start: 3px;
    padding-inline-end: 3px;
    padding-top: 2px;
    width: 1.2em;
    min-width: 1.2em;
    max-width: 1.2em;
    background-repeat: no-repeat;
    outline: none;
}

[lukewarlow]

#863 (comment) could it be due to the property limitations mentioned here? Or I guess if it's not using the pseudo element potentially not?

[scottaohara]

Is a marker element a way to solve this and the “checkmark” in the option element like we were talking about today?

something the browser renders if someone doesn’t add it (like the summary element in a details) but if someone does add it, the browser skips adding it and uses that instead?

If this is a bad idea, please disregard

[lukewarlow]

Hmm that's an interesting idea. Could apply the default hide this from accessibility tree behaviour. Would it require an SVG / img (well I guess anything) child or if you just included it on its own would it still use the default Glyph? Could that allow you to position it without needing your own SVG?

[josepharhar]

could it be due to the property limitations mentioned here?

No, considering that its still ::part(marker) that I'm using in the prototype.

something the browser renders if someone doesn’t add it (like the summary element in a details) but if someone does add it, the browser skips adding it and uses that instead?

I wanted to just change the color of it at first in which case I didn't want the browser to skip adding stuff, but in the case that I added content I did want the browser to skip adding it. I'm not sure exactly how this stuff would be implemented.

[josepharhar]

Should we encourage people to make their own <button type=selectlist> in order to customize the marker and consider getting rid of ::marker entirely if it isn't useful?

The more I think about it, the more appealing this sounds to me. I'd like to propose that we remove ::marker because imo it isn't very useful.

[scottaohara]

is there really no use case for this element to not be customized? i still see enough instances of rudimentary forms being implemented for internal use, where designers aren't assigned to projects and devs just use standard HTML elements without needing to gussy them up. I don't think it's a good idea to simply do away with the marker for default UA rendering, unless it's replaced with some other means of providing a default UA style for the chevron.

[josepharhar]

I think that if we replace the svg with a character that looks like the svg, like "⌄", then it would be more customizable.
So instead of this:

background-image: -internal-light-dark(url(data:image/svg+xml;base64,PHN2ZyB3aWR0aD0iMjAiIGhlaWdodD0iMTQiIHZpZXdCb3g9IjAgMCAyMCAxNiIgZmlsbD0ibm9uZSIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj5cCiAgPHBhdGggZD0iTTQgNiBMMTAgMTIgTCAxNiA2IiBzdHJva2U9IldpbmRvd1RleHQiIHN0cm9rZS13aWR0aD0iMyIgc3Ryb2tlLWxpbmVqb2luPSJyb3VuZCIvPlwKPC9zdmc+), url(data:image/svg+xml;base64,PHN2ZyB3aWR0aD0iMjAiIGhlaWdodD0iMTQiIHZpZXdCb3g9IjAgMCAyMCAxNiIgZmlsbD0ibm9uZSIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj5cCiAgPHBhdGggZD0iTTQgNiBMMTAgMTIgTCAxNiA2IiBzdHJva2U9IiNmZmZmZmYiIHN0cm9rZS13aWR0aD0iMyIgc3Ryb2tlLWxpbmVqb2luPSJyb3VuZCIvPlwKPC9zdmc+));

we would have this:

content: '⌄'

[lukewarlow]

I think the intention was to remove the marker pseudo but not to remove the default marker right? So the default UI would still look like currently?

[css-meeting-bot]

The Open UI Community Group just discussed selectlist: customizing the default button's marker is weird, and agreed to the following:

• RESOLVED: Keep ::marker pseudo element in selectlist. Further investigate exact implementation.

The full IRC log of that discussion

<gregwhitworth> q+
<Luke_W> q+
<masonf> q+
<keithamus> jarhar: making some examples, trying to deal with `:marker`, found it hard to manipulate, I think because it's implemented with an svg image data-url, so if I put color o it, it doesn't change. In the new anatomy I removed the marker slot, as it didn't seem worth having a whole new element. Should we have the element at all if it's not useful? If
<keithamus> we replaced svg with unicode character then it'd be more stylable. If not, we could just get rid.
<gregwhitworth> ack gregwhitworth
<gregwhitworth> q+
<gregwhitworth> ack Luke_W
<keithamus> Luke_W: given limitations of the pseudo, my gut says keep marker svg as default part of button, but get rid of pseudo to target, if they want to customise they can customise the button. pseudo element is going to be limited anyway. e.g. putting svg in there means setting display:none. If it doesn't work then no point keeping.
<scotto_> q+
<gregwhitworth> ack gregwhitworth
<keithamus> jarha: I think people will slot the button in which case the marker goes, so it's less important
<gregwhitworth> ack masonf
<flackr> q+
<keithamus> masonf: big disagree. Preferred approach is to replace svg with unicode, to allow at least the basic easy things to be customized, e.g. changing color. If they want more complex things you can't do svg, you can replace the button with your own, you've moved on.
<gregwhitworth> ack dbaron
<keithamus> dbaron: one option in addition is mask image, which is more obscure but might do the right thing with slightly more things; e.g. background (not color). Does that make sense?
<keithamus> argyle: that can be overwritten with background shorthand though
<gregwhitworth> ack scotto_
<gregwhitworth> q+
<keithamus> scotto_: would this be dropped with high contrast themes? We'll need a solution there too. I agree with Mason - I think it's important the default UA style has the chevron to show it's not just a regular button. Maybe people customizing select want it easy to customize, but we also need to have a good default UA for those just writing HTML
<gregwhitworth> ack flackr
<keithamus> flackr: can't svg use current color? I don't think we should limit to a utf8 char because of svg limitations that we can work around. Background mask feels a bit backwards, you're styling in the opposite direction. If you're trying to make a color scheme with background/foreground it gets flipped for just this thing.
<gregwhitworth> ack dbaron
<Zakim> dbaron, you wanted to react to flackr to comment on flackr's SVG point
<gregwhitworth> qq+ simon
<gregwhitworth> ack sim
<Zakim> simon, you wanted to react to dbaron
<keithamus> dbaron: if svg is separate file, there's an svg feature - contextcolor or something - that can be used
<gregwhitworth> ack simon
<keithamus> zcorpan: currentcolor doesn't work on data urls only svg in dom.
<masonf> q+
<jarhar> q+
<keithamus> gregwhitworth: even if you did currentcolor with background image you want to change fill color of svg. forced colors means changing the fills. Brings us full circle, let's be use case driven: my default feeling was pseudo elements never go far enough, we're in the same boat here with background image. To me, I'm for the unicode character because
<keithamus> of background/color context. Or i want the element there with a default svg. Those are my two preferences.
<gregwhitworth> ack gregwhitworth
<dbaron> There were some bugs that led me to try to change the calendar/clock icon in Chromium date picker controls to use mask, but I really wanted to use SVG context color, and I realized it was a bad idea because it was essentially a change to web-exposed behavior that might be too late to make. But I think SVG context color is probably the thing you want.
<gregwhitworth> ack masonf
<gregwhitworth> q+
<gregwhitworth> ack jarhar
<keithamus> masonf: echoing that. Important to remember 95% of actual users of this element will probably be customizing, it'll be in their design system. We're talking about the easy usecases of "i just want a select and want it to work". Also we need to standardise these styles across all browsers. I think it'll be easier to do so if it's just a unicode
<keithamus> character. They also solve for the "I just want a select and change its color"
<keithamus> jarhar: svg in the dom might solve our problems, but as Mason said, it'll be raised again in standards meetings, if anyone wants to help with trying svg in shadow dom we can try that and see if it works.
<keithamus> gregwhitworth: unicode character; will we end up with 4 different user agents rendering them drastically different - the emoji scenario?
<keithamus> dbaron: I'm worried different fonts are going to be different, not even different UAs, the same UA but different fonts.
<scotto_> just make it a span with border right, border bottom, rotate it 45deg. bam, consistent everywhere :P
<scotto_> (he says as if that's actually all there is to it)
<dbaron> https://www.w3.org/TR/SVG2/painting.html#SpecifyingPaint describes 'context-fill' and 'context-stroke' values
<keithamus> gregwhitworth: we want to ensure it looks identical across all UAs. If you can do svg in shadow root that's maybe better. What's type=selectlist bailout than a whole new element? Shadowroot can use fills, colors, people can adjust. We still need a pseudo element to achieve that though.
<gregwhitworth> q?
<gregwhitworth> ack gregwhitworth
<masonf> q+
<gregwhitworth> ack masonf
<keithamus> masonf: separate issue; are we really going for pixel perfect styling across all UAs? Slight differences in font would already fail. Is it a major concern if a down arrow looks slightly different?
<gregwhitworth> q+ argyle
<keithamus> dbaron: mostly some fonts give you tiny arrow, some give you huge - so it might be 3x variation in size.
<keithamus> masonf: if the UA sheet includes font rules?
<keithamus> dbaron: still depends on how wide spread fonts are. Maybe there are common fonts?
<gregwhitworth> ack argyle
<gregwhitworth> q+
<Luke_W> q+
<keithamus> argyle: when I'm on Linux or chromeos, I like my system font being there, I have to think less. Same for selectlist, I'd expect a system down indicator, nor normalised. I'm advocating for variety, the platform gets to make it look a natural member of the family.
<keithamus> gregwhitworth: 2 discussions happening: go with unicode, or go with svg. Personally to fully resolve, what David and Mason raised, can we sketch out the recommendations for styles with unicode, font rules, etc. Perhaps this would assuage a bunch of fears.
<argyle> q+
<keithamus> gregwhitworth: if we can validate that some styles prove out the multi UA/font concerns.
<masonf> q+
<gregwhitworth> ack gregwhitworth
<gregwhitworth> ack Luke_W
<gregwhitworth> q+
<keithamus> Luke_W: we can resolve that we all want to keep the marker pseudo - no matter what the implementation. Whether we expect it to be pixel perfect, the question of appearance base attribute comes up again. We don't need selectlist to be identical, provided we come up with a solution that works for all inputs. It would be great for developers to not
<keithamus> have to try too hard to make it consistent but if for example I change the font, I might want the down arrow to change. It just needs to be an indicator to a user, doesn't have to be perfect. Proposed resolution to keep marker, further investigation on how?
<gregwhitworth> ack argyle
<gregwhitworth> ack gregwhitworth
<dbaron> The other fun thing with a unicode character is centering it properly!
<Luke_W> Proposed Resolution: Keep ::marker pseudo element in selectlist. Further investigate exact implementation.
<gregwhitworth> ack masonf
<keithamus> argyle: +1 to unicode character. More in line with what I've been styling. svg might have stroke and fill... svg might be more modern but a little off the beaten path. Same for marker in list item, details summary marker, do we use paved paths? 2 unicode characters styled through a selector.
<gregwhitworth> q+
<keithamus> masonf: Resolution is good, keep `::marker`. More about the pixel match - we're not looking for pixel perfect matching but css UA style matching, so you know what you're overriding. Fonts don't have to be the same. I like Greg's suggestion - picking a unicode char and testing it, do the quick exploration.
<keithamus> gregwhitworth: When we worked on Edge interop - font sizing impacts layout. It becomes problematic. Times New Roman vs San Fransisco is one thing but layout dimensions need to be the same size. If they're inline and you're depending on intrinsic dimensions... 2 years ago we were default everything would be interop. I don't expect a glyph rendering
<keithamus> the same across fonts but 105px vs 100px in width is not interop.
<keithamus> masonf: shrink to fit div with a char in it isn't interop, on that definition
<keithamus> gregwhitworth: not trying to solve here but this is what I want to dig into. we need to re-evaluate if it's pixel perfect or are we okay with dimensionality being different.
<keithamus> masonf: I opened an issue on standardised styles.
<masonf> +1 to resolution
<Luke_W> RESOLVED: Keep ::marker pseudo element in selectlist. Further investigate exact implementation.

[josepharhar]

I am planning on experimenting with replacing the svg data url with an actual svg element in the user agent shadowroot to see if that it more stylable.

[github-actions]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.

[josepharhar]

Edit: moved to #863 (comment)

[josepharhar]

Whoops, that comment was meant for issue #863
I'll move it

[josepharhar]

I was able to make the default button's marker more customizable in this patch by replacing the background-image data url of the svg to an actual svg element in the dom tree, and setting its color with UA styles which target the pseudo-element. I don't see any reason not to do it this way, so I'm going to go for it.

[github-actions]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.

[josepharhar]

The default button's marker was replaced with select::after which has been renamed to select::select-arrow and will probably get renamed again here: w3c/csswg-drafts#10908

The new thing works much better because all properties apply to it and it uses the content property instead of an svg.