selectlist: Should the "checked" option have a checkmark next to it?

[josepharhar]

I touched on this while discussing #827

In order to indicate the currently selected option inside the listbox (I supposed it should also already be indicated in the button), should the currently selected/checked option in a single select selectlist have a checkbox rendered next to it?

For multi select, we would of course need this. For single select, maybe not?

The MacOS native select picker has a checkmark to the left of the selected option and also renders on top of the button which would otherwise indicate what the selected option is. The aria practices single select example has a checkmark to the right of the option: https://www.w3.org/WAI/ARIA/apg/patterns/combobox/examples/combobox-select-only/

If we did this, how would it be implemented? Just a user-agent style thats like option:checked::after { content: '✓' }? Or perhaps a new pseudo-element like ::checkmark? Should it be an SVG? Or be some sort of native checkbox thing? Should it be to the right of the option like the aria-practices example? Or should it be on the left? If it's on the left, should there be padding there for every option?

Whatever the case is, I feel like this should be easy for the developer to override/replace/remove, right @una? Would the content property in option:checked::after { content: '✓' } be easy enough to override? Should there be an easy way to move it from the left side of the option to the right side or vice versa?

@scottaohara @smhigley

[lukewarlow]

My gut feeling on this is don't bother providing a check by default at all. Instead just provide UA styles of the following (or something similar). This way the default is usable but it's ultimately up to the authors to make it nicer. Because I feel like adding a checkmark is just going to create more work for ourselves making a good way to style it (which will mostly just be removing it)?

option:checked {
  color: selecteditemtext;
  background-color: selecteditem;
}

Rendered:

[lukewarlow]

Happy to make a new issue for this but seeing as it's slightly related.

selectlist {
  accent-color: blue;
}

Does not seem to impact on any of the default UA styles (e.g hover state)

Should it?

[josepharhar]

adding a checkmark is just going to create more work for ourselves making a good way to style it

Agreed, in the OP I almost said "I have so many questions that I don't feel like this can be completed before we finish single select and move on to multi select".
If this isn't absolutely necessary from an accessibility point of view, then maybe we could save this for multi select.

Does not seem to impact on any of the default UA styles (e.g hover state)

Are these things already stylable via other CSS properties?
I created accent-color so that you could change the color of fully native form control elements like <input type=checkbox> which cannot be styled any other way.

[lukewarlow]

Yeah they can be styled by doing option:hovered option:focus-visible etc so it's not big deal. Just might be something that comes up from people who do

* {
   accent-color: var(--my-very-execellent-color);
}

[scottaohara]

so the pro of a checkmark marker for the default selected state is that it provides an overt visual "YOU CHOSE THIS" confirmation without having to have a strong (dark) default selected option background color - which if the decision ends up being to not have selection follow focus, we need to then have a strong focus indicator vs the strong background color. The checkmark loosens that a bit so the focus indicator could be a strong background color and then the selected state could be exactly the same as the unselected state - save for the 'checkmark' that appears.

the con then being that if no one wants that checkmark / if conflicts with people being able to identify a multiselect vs single select popup, then there's little in the way of default UA styling to fall back on for authors who just didn't want that default checkmark style - and they have to roll their own selected state and focus state.

keep in mind, that we do also need to consider how these selected vs unselected styles need to translate to windows high contrast mode - and since so many colors are kicked to the curb, a checkmark becomes another easy win for denoting the selected state vs the unselected state in that limited coloring scenario.

the above may make it seem like i'm advocating for the checkmark, but i'm personally a bit indifferent about it. it's just sorta factually beneficial to have it as a default UA style for ticking as many a11y boxes as possible for the default. These boxes can be ticked in other ways, it just means different things visual treatments need to be implemented/considered.

also i did not mean to make any sort of pun with talking about checkmarks and 'ticking boxes' and yet here we are. please clap.

[lukewarlow]

One potential issue with the checkmark is if you copy the option to <selectedoption> is it gonna copy with the checkmark?

At least on macOS this isn't the behaviour of select nor would it be what I expect?

[scottaohara]

not if it's a css marker specific to the option element and not selectedoption

[css-meeting-bot]

The Open UI Community Group just discussed selectlist: Should the "checked" option have a checkmark next to it?.

The full IRC log of that discussion

<hdv> jarhar: I wonder if we should show a checkmark next to items in a selectlist
<luke> q+
<hdv> jarhar: and if so there are lots of questions to be asked
<hdv> jarhar: scott had one comment: having a checkmark is very useful, a great way to indicate the current selection, but if we can find another way to do that, that would be fine too
<hdv> jarhar: some kind of styling that also works in high contrast mode, that would also be fine
<hdv> jarhar: not sure what that would be
<gregwhitworth> q+
<hdv> jarhar: this is probably also something to figure out for multiselect… a checkmark could probably work in select and multiselect btoh
<hdv> s/btoh/both
<hdv> jarhar: I welcome suggestions
<una> q?
<gregwhitworth> ack luke
<una> q+
<hdv> luke: I thought about it… one of those things where it is easy in CSS to apply and unapply styles… I think most people probably would throw away what we do… not sure if adding a checkmark is much value
<scotto_> q+
<hdv> luke: a background style may be easy enough, and then we don't need to worry about SVG vs pseudo el etc
<keithamus> q+
<hdv> luke: maybe it would need slightly different styling for focus
<gregwhitworth> ack gregwhitworth
<hdv> gregwhitworth: I don't disagree…we can probably do a forced color scheme mq to swap out the colours
<hdv> gregwhitworth: agreed we probably don't want checkmarks out of the box
<gregwhitworth> ack una
<nicole> q+
<hdv> una: my first instinct was also… developers want to customise this, is a large part of the goal of this
<hdv> una: currently select has a checkmark though on Mac, and if we want to stay uniform that seems good
<hdv> una: I would argue against using background as a way to distinguish, could have unexpected results
<hdv> una: similarly to having to undo the checkmark, having the undo the background isn't great
<hdv> una: the more I work on selectlist demos though, the more I want the ability to strip the native UI so you can do your own thing
<hdv> una: regardless of our decision here, having a way to easily undo UA styles would be great
<gregwhitworth> ack scotto_
<hdv> scotto_: my comment may become a new issue…
<hdv> scotto_: I agree that we shouldn't not do it because we think people are going to remove it… we can have strong defaults that are easy to remove
<gregwhitworth> q+
<gregwhitworth> ack keithamus
<hdv> keithamus: can we use accent color instead of background… and a ::marker ?
<gregwhitworth> q+ argyle
<hdv> [+1 to keithamus's suggestion!]
<gregwhitworth> ack nicole
<hdv> masonf: that works… but per the spec you can't mandate where accent colour goes (but can recommend it instead)
<hdv> nicole: I really like what keithamus just suggesed
<scotto_> to clarify further / repeat a bit from the issue. i don't have strong opinions on the default selected state. mac has the checkmark, windows doesn't. eh?
<hdv> s/suggesed/suggested
<hdv> nicole: we need to realise that styles are often where we solve user problems where developers might not know they exist… they may not test it on small screens or screenreaders
<gregwhitworth> ack gregwhitworth
<hdv> nicole: so with default styles we can make sure it works better for usrrs
<hdv> s/usrrs/users
<hdv> nicole: don't want to avoid shipping styles because they'd be hard to overwrite
<luke> q+
<gregwhitworth> nicole just covered my point
<hdv> nicole: I think re what una suggested… we should have a conversation about user agent styles and the ability to strip them out. Probably not for here now but we should probably talk about it in some venue
<gregwhitworth> ack argyle
<hdv> argyle: +1 to that
<hdv> argyle: in my own code I had accent color for the checked option and use my own pseudo
<gregwhitworth> ack luke
<hdv> luke: I agree with nicole that the UA styles should cover all user needs
<gregwhitworth> q+
<nicole> q+
<hdv> luke: I think background is clearer as a way to distinguish than a checkmark
<hdv> luke: it could work so that it was using the ::marker pseudo that would be easy to display:none
<hdv> luke: in terms of background color… I think a new system keyboard is being used on hover and focus styles
<hdv> luke: in forced color mode, the browser could swap them out
<hdv> luke: one down side for accent color is that a system color could not be easily swapped out
<masonf> Note on "stripping styles", this is discussed in https://github.com/w3c/csswg-drafts/issues/5998, and has been brought back up recently here: https://github.com/whatwg/html/pull/9546#issuecomment-1741629198
<gregwhitworth> q+ argyle
<hdv> luke: in webkit, accentcolor is 'fake' and set to blue
<nicole> q-
<hdv> gregwhitworth: there may be two resolutions here… one about should there be a checkmark
<una> q+
<hdv> gregwhitworth: the other about what are the styles and what are the implementation details of that selected state
<hdv> gregwhitworth: for that second one I would like to see a concrete proposal in the comment
<Cat_Johnson> q+
<hdv> gregwhitworth: seems like we're going into separate discussion
<hdv> masonf: to quickly answer that one, I'd like to answer them together because they are related in implementation
<hdv> gregwhitworth: I was asking from an end user perspective if the checkmark is bad to indicate rather than just colours in some form
<hdv> nicole: that's in WCAG, that you can't indicate with color alone
<gregwhitworth> ack gregwhitworth
<hdv> scotto_: I'm not super wedded to checkmark, but I brought it up because it's easier to recognise an icon than it is to recognise a change of colour
<keithamus> WCAG 1.4.1 https://www.w3.org/WAI/WCAG21/Understanding/use-of-color.html "Color is not used as the only visual means of conveying information"
<hdv> scotto_: I don't want to tell anyone they have to make a certain design, just whatever they want, it's radios or other icons in some platforms
<hdv> nicole: when we say checkmark we don't mean checkmark, right?
<hdv> scotto_: with the marker element, any UA could put whatever they want and developers could style it however they want too
<hdv> gregwhitworth: if we can't simplify the answer to checkbox, I'd want to see the implementation details and have it align between select and multiselect
<gregwhitworth> ack argyle
<hdv> argyle: I have a select multiple up on my screen here… multiple on mac doesn't show a checkmark currently, surprises me
<jarhar> select multiple on ios has nice checkmarks, and importantly is has empty circles for non-checked items
<gregwhitworth> Android does show them as radio options and fills in the circle on the selected option
<hdv> argyle: why don't we do it just like we would render a group of checkboxes, we already have accent colours there, ie let's follow the path that's already there
<hdv> scotto_: we would have to invent that though… visually looks like that but isn't actually what it is
<gregwhitworth> ack una
<flackr> q+
<hdv> scotto_: I do agree but we would need some convention
<scotto_> 'invention'
<hdv> una: I think the analogy of checkboxes inside of a popover is a bit like a :checked rfor a select
<hdv> s/convention/invention
<scotto_> :)
<nicole> q+
<hdv> una: it feels like ::marker is the most straightforward implementation of this feature… easiest to set and easy to remove. But tricky to get fill of the svg to work, probably need to restyle the ::marker
<masonf> q+
<hdv> gregwhitworth: such a can of worms
<luke> q+
<scotto_> to clarify: when i said someone would put in an SVG, i assumed they would actually add it in their markup. not via CSS
<hdv> argyle: as a user I like how checkboxes and selects take the accent color and I would like to see that here
<gregwhitworth> ack Cat_Johnson
<hdv> Cat_Johnson: gregwhitworth, you mentioned whether this should be enabled by default or not… my personal preference would be to enable by default
<jarhar> q+
<hdv> Cat_Johnson: in our design system, when other developers use our components, we enable things when we can, and make it easy to finetune the experience for developers if they want to
<gregwhitworth> ack flackr
<hdv> flackr: on Mac I see they do the background color thing, but as you hover over items it does change
<gregwhitworth> ack nicole
<hdv> flackr: talking about multiselect, I wanted to let people know, there are weird behaviours like keyboard ways to select 'items in between', something you couldn't do with a group of checkboxes, so it is different in ways like that
<hdv> nicole: developers are going to want to customise this… a solution that doesn't allow them to do that doesn't make sense
<hdv> nicole: like make icons to match their own icon libraries… so people will take this and turn it into their own things
<hdv> nicole: displaying a checkmark by default makes sense but we need to do it in a way where a lot of flexibility is allowed via CSS
<gregwhitworth> ack masonf
<hdv> flackr: I like it, similar to list item markers where you can replace those
<gregwhitworth> q+ to wind this issue down
<hdv> masonf: re flackr's point :we need to states, the selected item and the focused item
<hdv> s/to/two
<hdv> nicole: and a third, not selected?
<hdv> masonf: yes
<hdv> masonf: I see three ways forward: one is not support checkmarks, two is support via checked pseudo element, three is via some fully customisable SVG element
<gregwhitworth> ack luke
<hdv> masonf: we could try out the checked pseudo element route… I think it would work in 80% of cases and not be so easy in 20% … want to see how hard it is in those 20% of cases
<hdv> luke: I feel like ::marker is probably fine
<hdv> luke: in Chromium you can change the color of things like the calendar icon… can't remember how but you can
<hdv> luke: selectlist is already fully customisable… if you want an option with your fancy svg in it, you can already do it anyway
<hdv> luke: I don't think we need a way to replace the glyph because you could just display none the thing and do whatever you like to replace it
<hdv> luke: my proposal would be to use the ::marker pseudo, make it so that display:none makes it go away
<hdv> masonf: I meant to propose the same
<una> +1
<hdv> masonf: in developer guidance we could say you can change it like this, and you can fully replace it like this
<masonf> q?
<hdv> flackr: I heard a few times selection doesn't follow focus… it does seem to do that in some places, seems like that's on platforms that don't have checkbox
<gregwhitworth> ack jarhar
<hdv> scotto_: yes this is inconsistent between operating systems
<hdv> jarhar: I think I generally agree with Mason and Luke, and we need some time to investigate diffferent ideas
<una> q?
<hdv> jarhar: we should probably have people comment more on the issue with use cases
<hdv> gregwhitworth: I feel like we're all arriving at… solid proposal put forward, but maybe are use cases that are not covered
<hdv> gregwhitworth: jarhar can you do a proposal and request feedback from folks in the isuse?
<hdv> gregwhitworth: so that people can share use cases?
<hdv> gregwhitworth: jarhar or masonf ?\

[lukewarlow]

https://jsfiddle.net/cdygvmeb/23/ - Excuse the awful CSS but this kinda shows my thoughts on hey I want custom markers.

Just display none the marker pseudo put your SVG in the option and control it based on :checked pseudo class.

[flackr]

I just discovered that the existing ::marker pseudo has a really limited set of properties: https://developer.mozilla.org/en-US/docs/Web/CSS/::marker#allowable_properties . I suspect some developers would want to animate transform / opacity

For a more extreme animation example, have a look at the material checkbox animation: https://material-components.github.io/material-components-web-catalog/#/component/checkbox . This would probably require a custom component.

[lukewarlow]

My gut is that that's probably fine? As they can just do what I mentioned above and get the full capabilities? The reason checkboxes specifically are such a pain is exactly because they don't have full HTML abilities?

It's also worth being aware I think there's dicussion on making :marker less restricted for the details styleability but I may be mistaken with that.

[mfreed7]

My gut is that that's probably fine? As they can just do what I mentioned above and get the full capabilities? The reason checkboxes specifically are such a pain is exactly because they don't have full HTML abilities?

+1. It seems like the basic use case is "just" to have a visible checkmark next to the selected option. That's all you get currently on Mac platforms:

That's not a "checkbox" at all, it's just a "checkmark" which can be achieved (assuming we go this route) via

selectlist option:checked::marker {
  content: "✓"
}

I think that achieves 80+% of the use cases. You can pick your own marker, you can style it appropriately, etc.

For the 20% of use cases where you want more control, you're more on your own. But you can, e.g. use SVGs instead of just content via Luke's approach. Or if you want full interactive <input type=checkbox>'s inside the options, first, you're running afoul of #540 (comment). But if you manage to make that accessible somehow, you can use a similar technique of adding the checkboxes to your options, and hooking them up correctly via JS.

[scottaohara]

Yeah. Whatever can be done to make people NOT put a checkbox inside of something that already represents means of selecting a choice would be super great. This sort of misunderstanding happens far too often.

[flackr]

@scottaohara @mfreed7, to be clear I wasn't suggesting it is a checkbox or should have a checkbox put in it, but I could imagine developers wanting similar animations to the material checkbox checkmark animation, especially for the multi-select use case.

[scottaohara]

it was clear, sorry if my response made you think otherwise!

[mfreed7]

@scottaohara @mfreed7, to be clear I wasn't suggesting it is a checkbox or should have a checkbox put in it, but I could imagine developers wanting similar animations to the material checkbox checkmark animation, especially for the multi-select use case.

Yep understood! I just wanted to carefully make the distinction between checkmark and checkbox, since in the live discussion it felt a bit muddled. Maybe just to me.

[scottaohara]

when design treats checkmark and checkbox the same, it gets super muddled.

that screenshot is from fluent ui - where in the past that widget was incorrectly coded as checkboxes inside of options because "they look like checkboxes". it has since been fixed so that these are just visual checkboxes to represent the selected state of the option, but i get questions on a bi-weekly basis if "this is ok" because it "looks like" a checkbox but doesnt behave like one.

[flackr]

Right, agreed! Thanks for the example. I think this is good reason to make it easy to make something that visually looks like a checkbox as the marker so that there's an easy path which is semantically correct 🙂

[josepharhar]

So should we just have a user-agent style rule that looks like this? The visibility:hidden would add padding so the actual content of the options is still rendered at the same horizontal alignment.

selectlist option::marker {
  content: '✓';
}
selectlist option:not(:checked)::marker {
  visibility: hidden;
}

We could also use an svg or something instead of content, but that would be harder to add styling to - which might be good or bad, I'm not sure yet. It depends on whether we want to encourage people to display:none the ::marker in order to style it or not. The styling of this I think is related to #881

Also, this rule would probably not apply to options which are slotted in from outside the selectlist, which is something we probably want to support: #565

[scottaohara]

i like the visibility: hidden idea for the consistent padding

definitely would want that default UA style for the checkmark to be the following so we don't get an announcement of a "checkmark" along with the selected state.

selectlist option::marker {
  content: '✓' / '';
}

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

I threw together a work in progress patch to add checkmarks next to selected options by adding this to the UA stylesheet:

select option::before {
  content: '';
  display: inline-block;
  inline-size: 1.4em;
  block-size: 1.0em;
  background-image: url(data:image/svg+xml,%3Csvg%20width%3D%2220%22%20height%3D%2220%22%20fill%3D%22none%22%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%3E%3Cpath%20d%3D%22m8.229%2014.062-3.521-3.541L5.75%209.479l2.479%202.459%206.021-6L15.292%207l-7.063%207.062Z%22%20fill%3D%22%23000%22%2F%3E%3C%2Fsvg%3E);
  background-origin: content-box;
  background-repeat: no-repeat;
  background-size: cover;
}
select option:not(:checked)::before {
  visibility: hidden;
}

Here is a screenshot of what it looks like:

You can opt-out of it with option::before { display:none; }.

I feel like using ::before won't make it through the standards and maybe we would have to switch to ::marker or create a new pseudo-element, but is this what yall would like? Would having this by default get in the way of anything? Are there any improvements to the style rules I wrote that yall can think of?

[gregwhitworth]

Note that this is why I noted when I proposed a new need for a checkbox element it was due to none of these solutions actually meeting the needs devs have for simplistic style adjustments. I cover this quite in-depth in this older proposal for an indicator pseudo:

https://github.com/salesforce/standards-explainers/blob/master/indicator-psuedo/explainer.md#other-solutions-considered--faq

Effectively, to @josepharhar point if a UA wants to have them in the non-standardized scenario and handle the a11y that comes with that (whether it being swapping sheets, etc) then that is fine but I don't think we should do this in the default styles for select. So possibly we raise this to the agenda to resolve on whether we want that as a default style or not?

[lukewarlow]

I'd much prefer something like #863 (comment) (along with using the correct alt syntax with content attribute)

The fonts might change how it's rendered but I think that's probably fine. base appearance is mostly about stylability rather than everything being 100% identical (though we should aim to get as close to that as possible). But it's much much easier for styling. It just works with the color property. forced-colors (Windows' Contrast themes) mode can choose to just remove it entirely should it wish too.

[josepharhar]

I cover this quite in-depth in this older proposal for an indicator pseudo

Very nice! Yeah this has a lot of similarities with the checkbox we are talking about here

I don't think we should do this in the default styles for select

Why not? Your indicator proposal seemed to suggest that we should in fact use an svg instead of a unicode character.

The fonts might change how it's rendered but I think that's probably fine. base appearance is mostly about stylability rather than everything being 100% identical (though we should aim to get as close to that as possible). But it's much much easier for styling. It just works with the color property. forced-colors (Windows' Contrast themes) mode can choose to just remove it entirely should it wish too.

If the unicode character is more stylable then that's a good reason. I'm not sure if I could replace the svg background-url with a full on svg element in the dom unless I add it to the option element's UA shadowroot, which currently doesn't contain anything and just slots in all content.

[una]

For single select, I don't think the checked option should have a checkmark next to it by default.

1. This adds complexity in terms of design and UA style standardization
2. While this is a relatively common UI, it's not in the majority of selects. In my research, I've found one in about 20-25% of custom selects. This means users will need to "undo" the style frequently
3. It's easy to add the checkmark with custom user styles (see all of the suggestions above)

My question is -- is it an accessibility issue to add this checkbox via a background image and pseudo element content? This is how I imagine most would do it

[mfreed7]

I'm actually in favor of adding the checkmark, via ::marker or content:'✔️'. I've heard several times (would be great to get confirmation here) that it's an accessibility issue to only distinguish the selected vs. unselected options via color change. Having an explicit checkmark helps people who can't distinguish the colors. If that's true, I'd rather it be (just a bit!) of work for developers to remove the checkmark if they don't want it.

As a side-benefit, if we get this styling right, it'll feed naturally into the multi-select of the future, which needs checkmarks.

[josepharhar]

This adds complexity in terms of design and UA style standardization

Yeah it will be hard to standardize this, but it will also be hard to standardize the other hundreds of lines of css.

While this is a relatively common UI, it's not in the majority of selects. In my research, I've found one in about 20-25% of custom selects. This means users will need to "undo" the style frequently

I'd rather it be (just a bit!) of work for developers to remove the checkmark if they don't want it.

Yeah I'm hoping that it will just be option::bikeshed { display:none; } which would be pretty simple to turn off the checkmark

[css-meeting-bot]

The Open UI Community Group just discussed selectlist: Should the "checked" option have a checkmark next to it?.

The full IRC log of that discussion

<hdv> jarhar: there's an idea floating around that we need a visual indicator that is not just color on the currently selected option of selects
<hdv> jarhar: the native picker in macOS already does this
<hdv> jarhar: we could use ::before or other pseudos to put a checkmark there, I thought of using an svg to do that
<gregwhitworth> q?
<hdv> jarhar: sofar it seems most people in favour of doing a unicode checkmark
<una> q+
<masonf> q+
<sanketj_> q+
<Luke> q+
<hdv> jarhar: not sure if we want to resolve the method, but we could talk about what approach people prefer?
<gregwhitworth> ack una
<gregwhitworth> q+ naman
<hdv> una: thanks for bringing it up! I think this should not be part of default styling… it is very easy for developers to add this, including the two methods you've just mentioned
<hdv> una: second, I don't see this in many selects, looking at the Open UI research. Probably like 20%. It's out there but it's not most common
<gregwhitworth> q+
<hdv> una: third: this will also be hard to spec for user agents, because icons are usually branded and we would probably end up in discussions about things liek spacing and more
<hdv> una: I think the iOS browsr is the only one that does it now
<hdv> una: would probably be easier to resolve on 'this is a developer addon' rather than adding it into the default UA stylesheet as something developers need to undo
<gregwhitworth> ack masonf
<brad_frost> q+
<bkardell_> on MacOS Safari there is also a checkmark
<brad_frost> (Am I doing that right?)
<hdv> masonf: I'd love confirmation… all of my opinions are based on what I heard from accessibility folks, that we need to have a way to show the current option that is not just colours
<scotto> q+
<hdv> masonf: can someone say I'm wrong if I'm wrong… but otherwise I think the accessible thing should be the thing we do by default
<keithamus> > SC 1.4.1:Use of Color (Level A)
<keithamus> > Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.
<una> q?
<hdv> masonf: if agreeing on icon etc is difficult, I think we should make it a unicode character, there is a checkmark character, which is interoperable and understandable and would be easy to remove
<hdv> masonf: we are going to work on select multiple. I think everyone will agree that one needs checkmarks? so this would be a natural part
<hdv> una: I don't think an icon the only way to make it accessible… there could be other visible changes
<hdv> una: also would adding a unicode character cause it to be read out in addition to the already available selected state of the option?
<gregwhitworth> ack sanketj_
<hdv> sanketj_: una largely covered what I wanted to say
<hdv> sanketj_: the checkmark pattern seems to be only on specific platform. I agree with the premise that we should make these components accessible by default, but not sure this is the way
<hdv> sanketj_: if this is not used much in selects, I haven't seen it too much in my research to custom selects on the web, then probably opt-in makes more sense
<gregwhitworth> ack Luke
<hdv> Luke: I don't think we should use existing customisable selects as the pinnacle of what accessible selects should look like, they generally have problems for keyboard users, sighted users, screenreaders users et
<hdv> Luke: but agree using colour alone isn't good enough so we need something
<hdv> Luke: I think disabling the marker would be quite trivial to do in CSS
<hdv> Luke: content does have a way that isn't read out by a screenreader, we would definitely want to use that
<hdv> Luke: I personally think we should have the checkmark by default on the checked option
<hdv> Luke: it's accessible and it gets the point across
<gregwhitworth> I have to drop, I have opinions on this as I don't like the default being backgrounds or unicode characters as you can't meaningfully customize them and thus pseudo solutions are not preferred
<gregwhitworth> ack gregwhitworth
<hdv> Luke: the main thing we want is a select that you customise, and that would very much be possible with this. From that perspective it makes sense for us to put as much accessible stuff in there by default as possible
<hdv> Luke: I prefer content to background… only thing maybe is that choice of font would impact how it is rendered
<hdv> s/thing/issue with that approach
<jarhar> q?
<hdv> ack nam
<hdv> naman: I think everything I was going to say has been covered
<hdv> naman: I think the unicode sets the wrong example, SVG background makes more sense to be… but don't have strong opinion on it
<una> q+
<hdv> flackr: doesn't it offer a more per platform customisation as to what that looks like on that platform?
<hdv> masonf: comes with default font
<hdv> flackr: yes
<hdv> naman: you've convinced me
<flackr> q+
<hdv> ack brad
<flackr> q-
<hdv> brad_frost: hi I'm Brad. we've had conversations about a global design system and wanted to give an update on that
<AzPrison> Hey flackr and hdv whats good
<hdv> masonf: should we put it on the agenda?
<hdv> brad_frost: sounds good!
<hdv> masonf: maybe this week… if you want to open an issue and set it to agenda+
<hdv> masonf: and thanks for the contribution!
<dbaron> I think there's already an issue for the global design system discussion at https://github.com//issues/1017
<hdv> scotto: una's correct… for accessibility the distinction for not relying on color alone, it doesn't have to be a checkbox
<AzPrison> dbaron whats up
<hdv> scotto: agree with a bunch of things that were said
<hdv> scotto: having said that, I'm more on the side of having a checkbox there by default
<AzPrison> yo hdv hit me back
<AzPrison> hdv hit me back
<hdv> scotto: if we end up not wanting to go with a character… we probably want a strong contrast in background to indicate current item… but then are people going to want to use it?
<hdv> scotto: if someone will change the background colour and it becomes something that isn't super accessible, it would be great to have the checkmark there as a fallback
<hdv> scotto: and if it's a unicode character it would also respect things like high contrast mode
<AzPrison> hdv scotto i can really help you guys with the character let me no youll want to hear my ideas
<masonf> q?
<masonf> ack scott
<keithamus> q+ naman
<masonf> ack una
<keithamus> q+
<hdv> una: to give you a few examples… on Facebook emoji picker the biggest change in what you've selected is the selected option
<hdv> una: another example is the AirBnb country picker… a checkbox woulnd't fit there in the way we're thinking about it
<AzPrison> are you guys see my emails
<AzPrison> hdv una scotto: hit me back asap
<hdv> una: in a lot of examples of 'styleable selects' in the wild, the current item looks quite different and having a checkbox would not look appropriate, and would cause devs having to remove it
<masonf> q?
<hdv> una: having to remove the icon would be an extra step for developers I'd like to avoid if we can
<masonf> ack naman
<hdv> naman: to una's comment… I think there's two motivations here… one is can we give the most accessible default possible, and be defensive against developers doing the wrong thing… two is can we avoid pain for developers if they are going to customise and make it as easy of posible
<hdv> naman: when we think of defaults… do we expect developers to make the selected state accessible with every single one?
<hdv> naman: having an accessible default would be my preference
<una> but in that case, developers are still "undoing" and adding their own icon
<sanketj_> q+
<hdv> naman: in a single select you can think of a dropdown as a list of radiobuttons, whereas multi select is more like a list of checkbox, would it make sense to make it more radio-y?
<hdv> keithamus: I think it's probably been said enough… but wanted to state the obvious: there are discreet groups of people that we hope to anticipate the actions of: those who never style these things, vs those who always do
<hdv> keithamus: una had great examples of where the defaults wouldn't work
<brad_frost> q+
<masonf> ack keith
<hdv> keithamus: in our design system at GitHub we tweak pretty much all of the default style… and I think that's quite common
<masonf> ack sanket
<hdv> keithamus: and then maybe there's a third camp: those who customise badly and break accessibility
<jarhar> q+
<hdv> sanketj_: to address that category of those people who never customise: at least in Chromium we have a focus ring that we use on a variety of controls… 
<hdv> sanketj_: is there really a need to bring in a default that is not commonplace?
<hdv> masonf: since selection doesn't follow focus, you need two patterns
<hdv> una: I think you run into the same problem, that people would still need to undo/redo it for their own styles
<jarhar> q-
<hdv> sanketj_: the meta point is… can we reuse existing patterns that are there
<brad_frost> q-
<hdv> masonf: yeah so bold text, other icons, etc could be other ways to do it
<hdv> q?
<hdv> masonf: is there anything we can resolve on today on this?\
<hdv> scotto: I kind of forgot about the selection follows focus thing and the moving away from that… I think there was going to be a change on Windows… but with that, it becomes even more important to distinguish between selected and focused, so like a checkmark that stays in place while user traverses with arrow keys
<hdv> una: if we do add an icon…it's not just adding the icon, it's also adding the spacing of the option to create space for the icon… that makes opt out a little harder
<hdv> jarhar: what I suggested doing earlier, is to set the checkmark on every single one of them and then the one's that aren't suggested are visibility hidden, then display none'ing them all gets rid of them all
<hdv> masonf: what I hear today is we're worried it would be hard to get rid of the default… would it be reasonable path forward for us to prototype?
<hdv> masonf: eg if we find a way to make it one line of code that's easier to discuss?
<hdv> una: having one line of code isn't necessarily my biggest concerns… it's also changes the architecture of what an option is? like the form of the option
<hdv> dbaron: one little thing to add to what masonf was saying: one other thing to consider, can you do things like move the character to the other side?
<hdv> masonf: good point
<masonf> ack dbaron
<hdv> una: customising would get more complex as you have the think about the icon and how it relates to the option text
<hdv> keithamus: my point was kind of… customisers are going to customise
<scotto> q+
<hdv> keithamus: I think people would be ok to do a lot of customising
<hdv> una: but one of the more basic examples… a flag icon in a list of countries… would the author expect the checkmark to go away or move somewhere? what would they expect?
<masonf> ack scott
<hdv> keithamus: in our guidelines… if you have visual identifiers, you get rid of the checkmark… we had the conversation here and put it into the guidelines, and definitely noted the distinction but I don't think the issue was authors using the component necessarily
<masonf> q+ naman
<hdv> scotto: to reiterate what keithamus says… people have to remove a lot of styles anyway…and one of the things people do with styleable selects is also to add a lot of complexity
<masonf> ack naman
<hdv> naman: the regular patterns seems to be that appearance:none gets rid of default styles, isn't that something that could be done here?
<hdv> masonf: I think what you're requesting is already done
<hdv> naman: that makes I'm more in favour of checkboxes
<hdv> una: but you can't use appearance: base-select and appearance none at the same time
<hdv> una: can't have them both at once
<una> I appreciate your thoughts everyone!
<hdv> masonf: feel free to chime in if you have more thoughts on the issue

[css-meeting-bot]

The Open UI Community Group just discussed selectlist: Should the "checked" option have a checkmark next to it?, and agreed to the following:

• RESOLVED: support checkmark next to checked option, implemented via the content property on the ::marker pseudo element. The UA should set a Unicode character by default, which isn't read out by screen reader.

The full IRC log of that discussion

<hdv> masonf: we talked about this a few weeks ago. We had no resolutions then… question is: should there be a checkmark? and should it be there only for select multiple or also with single selects?
<hdv> keithamus: one issue was around: if we're going a unicode char, which one and will it be read out ok by a screenreader? and if not would it be easily customisable by devs?
<hdv> masonf: there is a natural unicode character that would fit here, which is called checkmark
<masonf> q?
<hdv> masonf: but then the question remains how easy it is to replace the icon for developers?
<hdv> masonf: maybe it'd be helpful to write down what it would look like in CSS and what it would look like in the UA stylesheet, so that it's easier for us all to look at it
<hdv> keithamus: open question for me is: what selector would it use? `option::checked`?
<hdv> masonf: would make sense to me?
<keithamus> ```
<keithamus> select option:checked { content: ''; }
<keithamus> ```
<hdv> Luke: there was also talk of a marker pseudo el
<hdv> keithamus: if we're just overriding the `content` property, would `content: ''` the correct way to override it?
<Luke> `option:checked::marker { content: 'tick' }`
<masonf> q?
<hdv> masonf: yes that would work, or whatever other method you could use
<hdv> q+
<brecht_dr> q+
<keithamus> q+
<hdv> Luke: this seems good to me, easy to replace it and easy to display none it
<hdv> Luke: and this is not hard to undo
<hdv> masonf: +1 to that!
<flackr> q+
<masonf> hdv: I agree with Luke. Seems like a good idea, easy to replace, easy to get rid of. Nice!
<masonf> hdv: content is also read out by screen readers, it's in the a11y name and description spec.
<masonf> Luke: there is a syntax to make that work correctly, with a trailing slash.
<masonf> ack hdv
<hdv> hdv: and we could even do in the UA stylesheet?
<hdv> Luke: yes
<hdv> brecht_dr: also +1 from me
<masonf> ack brecht
<masonf> ack keith
<hdv> brecht_dr: this seems like something people would want to remove and this seems to make it easy to do that
<hdv> keithamus: it seems straightforward
<hdv> keithamus: I know people found it tricky with `popover` on my team that `open` was the inverse state, but with this that doesn't seem like a big deal
<masonf> ack flackr
<hdv> flackr: looks good to me… but isn't `content: none` the way to turn it off?
<hdv> Luke: but would `display: none` help with also remove everything else like padding
<masonf> Proposed resolution: support checkmark next to checked option, implemented via the content property on the ::marker pseudo element.
<hdv> flackr: yes but content: none should also not draw a box
<keithamus> +1
<hdv> Luke: I think the only concern last time was 'is this a good idea to do as a default'… I think the consensus was that yes it is a good idea
<hdv> Luke: can it be rendered consistently and removed easily would be my two criteria
<hdv> masonf: yes I feel like having it on by default and easy to remove is good.
<hdv> masonf: when it comes to SVG or unicode char, I feel unicode char is easiest because standardised, SVG would maybe cause more bikeshedding
<brecht_dr> +1 to what Mason said there
<hdv> Luke: and good thing is if you change the font it can follow your font
<hdv> Luke: one advantage of SVG would be that currentcolor could be used and follow colours
<masonf> Proposed resolution: support checkmark next to checked option, implemented via the content property on the ::marker pseudo element. The UA should set a Unicode character by default.
<keithamus> +1
<masonf> support checkmark next to checked option, implemented via the content property on the ::marker pseudo element. The UA should set a Unicode character by default, which isn't read out by screen reader.
<keithamus> +1
<Luke> +1
<brecht_dr> +1
<hdv> flackr: another good reason for unicode char is that it would follow OS convention
<hdv> +1
<masonf> RESOLVED: support checkmark next to checked option, implemented via the content property on the ::marker pseudo element. The UA should set a Unicode character by default, which isn't read out by screen reader.

[josepharhar]

I created an explainer PR here: #1059
I am implementing this in chromium here: https://chromium-review.googlesource.com/c/chromium/src/+/5578818

[yisibl]

I strongly object to using ::marker to style checkmarks, because ::marker can only have a limited number of CSS properties(#863 (comment)), which severely constrains authors from customizing styles. For example, it's not easy to right-align icons(The third case in the figure). Perhaps we could add a new pseudo-element so that it doesn't take up the ::before or ::after position.

I've heard several times (would be great to get confirmation here) that it's an accessibility issue to only distinguish the selected vs. unselected options via color change. Having an explicit checkmark helps people who can't distinguish the colors.

Yes, I'm in favor.

---

Regarding the cross-platform styling inconsistencies brought about by using Unicode characters, I think this can be solved by using the icon font technique, which is widely implemented for icon components on the Web. We now have the COLRv1 font format, which can even do gradient colors.

Demo: https://codepen.io/yisi/pen/NWVbZOY?editors=0100

@josepharhar One question is, can a browser use @font-face in a UA style to load a base64 font?

[lukewarlow]

I strongly object to using ::marker to style checkmarks, because ::marker can only have a limited number of CSS properties(#863 (comment)), which severely constrains authors from customizing styles. For example, it's not easy to right-align icons(The third case in the figure). Perhaps we could add a new pseudo-element so that it doesn't take up the ::before or ::after position.

So while this is true, it's possible that we can loosen some of these restrictions in this case, OR it's fine because for any non-standard usages of it they can just hide it and do the marker themselves. Importantly though we should be able to do right to left in the browser using this model if the marker should move in right to left contexts.

[yisibl]

Importantly though we should be able to do right to left in the browser using this model if the marker should move in right to left contexts.

Using a pseudo-element like ::before does not affect changing the direction of the text, I added it to the demo.

Using a pseudo-element like ::before does not affect direction to change the direction of the text.

But with ::marker the value of display becomes list-item, and we lose the possibility of using other layouts. No matter how much you add to the properties allowed by ::marker, this cannot be changed under the current specification.

The ::marker pseudo-element represents the automatically generated marker box of a list item. (See [CSS-DISPLAY-3] and [CSS-LISTS-3].)

A list item is any element with its display property set to list-item. List items generate ::marker pseudo-elements; no other elements do.

This problem already exists in <details>, I hope we don't have to make the same mistake.

[lukewarlow]

Sounds to me like that spec might need work regardless. But that's fair if it's very heavily specced and setup a certain way we can probably mint a new pseudo, or use before as Joey currently is.