WICG / webcomponents

Web Components specifications
Other
4.39k stars 376 forks source link

Manage pseudo class matching state for custom elements #813

Open tkent-google opened 5 years ago

tkent-google commented 5 years ago

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

enqueue commented 2 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.

justinfagnani commented 1 month ago

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")?

rniwa commented 1 month ago

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.