[selectors] Shouldn't there be a pseudo selector for `:unchecked` inputs?

[bluemoehre]

Currently the :checked and :indeterminate pseudo-classes can apply to a <input type="checkbox" />:
https://drafts.csswg.org/selectors/#checked
https://drafts.csswg.org/selectors/#indeterminate

But to apply styles for an unchecked checkbox, you must use :not(:checked).

Regarding other selectors there is always a negative variant:
https://drafts.csswg.org/selectors/#enabled-pseudo
https://drafts.csswg.org/selectors/#disabled-pseudo
https://drafts.csswg.org/selectors/#required-pseudo
https://drafts.csswg.org/selectors/#optional-pseudo
https://drafts.csswg.org/selectors/#valid-pseudo
https://drafts.csswg.org/selectors/#invalid-pseudo
https://drafts.csswg.org/selectors/#user-valid-pseudo
https://drafts.csswg.org/selectors/#user-invalid-pseudo
[...]

Having very specific design rules, it feels a bit off and somehow degrades readability:

input:enabled:checked { ... }
input:enabled:checked:hover { ... }
input:enabled:not(:checked) { ... }
input:disabled:checked { ... }
input:disabled:not(:checked) { ... }

So for convenience: why don't we have an :unchecked ?

[LcsGa]

Whereas I get the idea, then we could add :unhover, :unfocus, etc. which feels weird in my personal opinion.

[SebastianZ]

The difference to :hover or :focus is that the checked state is something defined within HTML, like the disabled or optional state. And it is also part of form elements for which we already have the negative variants, so an :unchecked pseudo-class aligns with them.

Sebastian

[LcsGa]

I didn't see things that way! You're right! 😁

[JoshTumath]

Agreed. Authors will probably be expecting an :unchecked pseudo-class, and I imagine that it wouldn't be too much effort for user agents to implement support for this. An easy win.

[bluemoehre]

So, what's the next step? Should I bring up a PR? (I'm kinda afraid - haha 😄)

[SebastianZ]

As this proposal seems reasonable, the next step is for the CSS Working Group (CSSWG) to discuss it and resolve on whether to add this feature or not. Therefore, I marked this issue with the Agenda+ label.

@bluemoehre If the working group decides to add this feature, you are welcome to provide a PR for it. Members of the working group will guide you.

Sebastian

[LeaVerou]

On one hand, we do have both :enabled and :disabled, :valid and :invalid. A crucial point is that these are not equivalent to the :not() versions of the positive pseudo-class. :disabled is not simply :not(:enabled) as the latter would also match elements that cannot be activated. Similarly, :invalid is not simply :not(:valid).
I think :unchecked could work similarly, and only target checkboxes and radios.

[tabatkins]

I won't be around for this discussion, so just commenting here: sounds fine to me? The point that we have a bunch of boolean pseudo pairs does suggest a pattern we should maintain for author convenience. We can target the same set of elements using :not(), since the set of elements :checked can apply to are very limited in the first place; input[type="checkbox"]:not(:checked) (or [type="radio"]), but granted that's pretty long. ^_^

I was going to say something about ElementInternals and form-associated custom elements, but it seems that that API doesn't currently have a way to associate an element with :checked anyway. That might be something we should think about in the future; if we do add such an API, it will need to be able to distinguish between checked/unchecked and not checkable. (It'll already need to be a multi-state concept anyway, to handle :indeterminate.) Anyway, that's a tangent and not germane to this issue.

[css-meeting-bot]

The CSS Working Group just discussed [selectors] Shouldn't there be a pseudo selector for `:unchecked` inputs?, and agreed to the following:

• RESOLVED: Define :unchecked for elements for which :checked applies, exclusive with :indeterminate

The full IRC log of that discussion

<emilio> fantasai: proposal to have :unchecked, parallel to :checked and :indeterminate
<emilio> ... parallel to other pseudos like :enabled/:disabled
<emilio> ... apparently this one is the only one that doesn't have it
<emilio> ... proposal is to add it
<emilio> Rossen9: so when does this match?
<emilio> fantasai: when it can be checked but isn't
<emilio> q+
<Rossen9> ack emilio
<fantasai> fantasai: e.g. div:not(:checked) matches but div:unchecked doesn't
<fantasai> emilio: is it exclusive with :indeterminate?
<fantasai> fantasai: yes
<emilio> fantasai: because indeterminate means it's not checked or unchecked
<emilio> dbaron: checked can match radio/input/option
<emilio> ... indeterminate can match radio/checkbox/progress
<kizu> q+
<emilio> ... I assume this would match only the things checked might match?
<emilio> fantasai: yes
<dbaron> https://html.spec.whatwg.org/multipage/semantics-other.html#selector-checked
<Rossen9> ack kizu
<emilio> kizu: in scroll-marker :checked was mentioned as something we'd match
<emilio> ... should we have :unchecked too?
<emilio> fantasai: I think we shouldn't have :checked for that
<emilio> flackr: if we use :checked it probably should
<kbabbitt> :unchecked sounds good to me
<emilio> PROPOSED: Define :unchecked for elements for which :checked applies, exclusive with :indeterminate
<emilio> RESOLVED: Define :unchecked for elements for which :checked applies, exclusive with :indeterminate