-
Notifications
You must be signed in to change notification settings - Fork 197
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
selectlist: pseudo-class to style the selected option #827
Comments
Did some playing around and for And you can apply some styling to it however |
The :checked pseudo class can be used now with select and selectlist but a :selected pseudo class would make far more sense, imo, but retaining support for :checked could be useful… |
Yeah I think I agree that it'd be nice to add a |
dunno. but guess that comes down to what the end goal for multi-select ends up being. e.g., someone could end up needing to convey both a 'checked' and a 'selected' state - which is why in ARIA options support both. It's not a common thing, and tbh due to it not being common, it is handled inconsistently / not something that is at the top of people's todo lists to sort out. but, hey... priorities n' such. |
Oh cool, I didn't know that |
The Open UI Community Group just discussed
The full IRC log of that discussion<gregwhitworth> ack lukew<hdv> lukew: selectlists currently have options inside of them, one of them can be selected. Joey opened an issue to come up with a pseudo class to style it based on whether it is selected or not <hdv> lukew: I found out there's a :checked pseudo class that you can already use today <hdv> lukew: also works for select[multiple], and it works for selectlist currently <hdv> lukew: so I wonder if we need something specific for this or if :checked is sufficient <gregwhitworth> q? <hdv> lukew: would also like to know more about the difference (in ARIA) between aria-selected and aria-checked <hdv> scotto_: in ARIA there is the concept of an option that can be checked or selected… this goes into multi select territory… generally selection follows focus inside of a listbox <hdv> scotto_: if it is a single select, the selected option is the focused option, they're one and the same. But then in a multiselect, that becomes a bit more difficult to parse, what is selected may not actually be what is focused <hdv> scotto_: you can do that by marking indivual options as selected <masonf> q+ <hdv> scotto_: selection could also follow focus, what then shows is now checked instead of selected <hdv> scotto_: I don't know if that's a good idea or a bad idea… but listboxes and the selected state is handled very differently between browsers and assistive technologies <gregwhitworth> ack masonf <hdv> masonf: thanks for that <jarhar> q+ <sarah_h_> I think the simplest recommendation would be single select > selected state; multiselect > checked state <hdv> masonf: if we already have checked and the behaviour does the thing we want… my guess would be it would be hard to get another one that does the same thing in CSS or WHATWG <kizu> q+ <hdv> masonf: maybe we can wait with this until we have selectlist[multiple], then it would become relevant <brecht_dr> q+ <gregwhitworth> ack jarhar <hdv> jarhar: I like mason's idea <hdv> jarhar: from the ARIA practices, in an example there is checkbox next to the selected option <hdv> jarhar: in the single select, the currently 'commited' option , would it make sense to have it show a checkmark? <hdv> scotto_: LOL. well… there are a lot of ways to design for this and convey this, it doens't have to be a checkmark <gregwhitworth> q? <brecht_dr> q- <hdv> sarah_h_: my recommendation for selected vs checked would be the opposite… checked for multiselect makes sense vs selected for single <hdv> sarah_h_: remind me, for selectlist, does selection follow focus? <hdv> jarhar: i made it stop doing that <hdv> sarah_h_: if selection doesn't follow focus we could use selected for everything… aria selected has many historical issues, but it works reasonably well <hdv> sarah_h_: might have a slight implication if there's' multiselect <gregwhitworth> ack kizu <hdv> scotto_: radios and menuitem radios use checked too… so there's always going to be weird cases <hdv> kizu: we had a lot of weird cases with select… some of them were this distinction between current state of select, submitted state for the input vs what you're selecting, then the selection could lead to other UI to do stuff, like to show extra information <sarah_h_> just to clarify in minutes: if selection does not follow focus, we could just use checked for everything. aria-selected only works well for single-select where selection follows focus <lukew> q+ <hdv> kizu: even for a single select there is a submitted state and not yet submitted state… in which case it would be both selected and checked maybe?> <gregwhitworth> ack lukew <hdv> lukew: so it looks like we come back to Mason's proposal? stick with selected? <masonf> Proposed resolution: The :checked pseudo should work for selectlist. Wait to think about :selected until we're discussing <selectlist multiple>. <lukew> +1 <brecht_dr> +1 to this <hdv> s/selected/checked <sarah_h_> +1, though I think we'll especially not want selected for multiple :D <masonf> RESOLVED: The :checked pseudo should work for selectlist. Wait to think about :selected until we're discussing <selectlist multiple>. <jarhar> agreed sarah_h_ |
I filed another issue to talk about rendering checkmarks next to options: #863 |
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. |
The selected option in the listbox should be easy to style independently from the other options.
A pseudo-class like
option:selected
would make sense for this, right?Is there already another way to do this that I'm missing?
The text was updated successfully, but these errors were encountered: