Open tkent-google opened 5 years ago
While working with custom states via CustomStateSet
and documenting their use is a viable option for component library authors, from a user's perspective it would be more intuitive to use the known standard CSS selectors.
There seems to be a rule in place for :disabled
, which works. :invalid
works, too, when setting the validity via ElementInternals
. Unfortunately the selectors mentioned in this ticket, which are really related to input and other form associated elements, are currently not supported.
I've been building form elements recently and could really use the ability to act like a checkbox and use standard validation-related pseudo-classes.
What's needed to manage these with CustomStateSet? Do we need a separate set because this state isn't custom? Or can we just use the colon-prefixed names, like internals.states.add(":checked")
?
I don't think we want this to be a feature on CustomStateSet
. If a checkbox is checked, we also need to convey that for AT as well. It makes more sense as an extension to ElementInternals
since we already support matching :invalid
, :out-of-range
, etc... with ElementInternals
.
Providing a way to make a custom element matchable to the following pseudo classes would be helpful.
:checked, :indeterminate, :in-range, :out-of-range, :required, :optional, :read-only, :read-write
Usecase: A web author makes a checkbox-like custom element, and want to support
:checked
pseudo class like the built-in<input type=checkbox>
.We discuss a similar feature at https://github.com/w3c/webcomponents/issues/738. Its selector syntax is something like
:state(checked)
, and it's not compatible with built-in elements.Proposal and feedbacks: The initial idea was https://github.com/w3c/webcomponents/issues/738#issuecomment-483907256 . There is a concern about difficulty of correct usage; https://github.com/w3c/webcomponents/issues/738#issuecomment-484965515