Skip to content
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

Closed
josepharhar opened this issue Sep 6, 2023 · 8 comments
Closed

selectlist: pseudo-class to style the selected option #827

josepharhar opened this issue Sep 6, 2023 · 8 comments
Labels
select-v2 Features regarding the second iteration of the selectmenu element stale

Comments

@josepharhar
Copy link
Collaborator

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?

@josepharhar josepharhar added the select These are issues that relate to the select component label Sep 6, 2023
@lukewarlow
Copy link
Collaborator

Did some playing around and for <select multiple> it's option:checked

And you can apply some styling to it however select:-internal-list-box:focus (exact name might be slightly different) has some errors that mean that you can't properly style the background or foreground colour.

@scottaohara
Copy link
Collaborator

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…

@lukewarlow
Copy link
Collaborator

Yeah I think I agree that it'd be nice to add a :selected pseudo and alias :checked to it for options. I wonder if that'd get push back as being superfluous though?

@scottaohara
Copy link
Collaborator

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.

@josepharhar
Copy link
Collaborator Author

Oh cool, I didn't know that option:checked worked. Yeah I agree we should at least make :checked work if it doesn't already, and then also add option:selected if people are cool with it - and if some people say we can only have one, then option:selected it is.

@una una added the agenda+ Use this label if you'd like the topic to be added to the meeting agenda label Sep 28, 2023
@css-meeting-bot
Copy link

The Open UI Community Group just discussed selectlist: pseudo-class to style the selected option, and agreed to the following:

  • RESOLVED: The :checked pseudo should work for selectlist. Wait to think about :selected until we're discussing <selectlist multiple>.
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_

@josepharhar
Copy link
Collaborator Author

I filed another issue to talk about rendering checkmarks next to options: #863

@josepharhar josepharhar added select-v2 Features regarding the second iteration of the selectmenu element and removed select These are issues that relate to the select component labels Oct 6, 2023
@gregwhitworth gregwhitworth removed the agenda+ Use this label if you'd like the topic to be added to the meeting agenda label Oct 10, 2023
Copy link

github-actions bot commented Apr 8, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
select-v2 Features regarding the second iteration of the selectmenu element stale
Projects
None yet
Development

No branches or pull requests

6 participants