Re: [w3c/webcomponents] Custom pseudo-classes for host elements via shadow roots (:state) (#738)

@rakina Thanks for writing that proposal. It looks like it should meet our needs.

One question: it's worth considering the parallelism of 1) setting of custom states and built-in pseudo-classes and 2) the application of styles to custom states and pseudo-classes. Above @tkent-google suggests using a colon in the parameter passed to `states.add`, as in `states.add(':checked')`. That would give the following matrix:

* Set custom state: `this.#internals.states.add('foo')`
* Set built-in pseudo-class: `this.#internals.states.add(':checked')`
* Use custom state: `my-element:state(foo)`
* Use built-in pseudo-class: `my-element:checked`

The above feels a little rough to me. A minor issue is that it feels odd to have a micro-syntax for the parameter to the `states.add` method. But a bigger issue is that the API call for setting a custom state or a built-in pseudo-class is essentially the same — but the CSS for referencing those two things are completely different. Moreover, as @othermaciej observes, "While some CSS pseudo-classes represent internal states, others, such as :nth-child, :matches and :empty don't represent internal states, but rather express conditions about the structure of the DOM."

I wonder if it'd be cleaner to try to use the term "state" in the API to always refer to custom state, and "pseudo-class" to always refer to built-in pseudo-classes:

* Set custom state: `this.#internals.states.add('foo')`
* Set built-in pseudo-class: `this.#internals.pseudoClasses.add('checked')` (note: no colon)
* Use custom state: `my-element:state(foo)`
* Use built-in pseudo-class: `my-element:checked`

This keeps custom state and built-in pseudo-classes separate.

In documentation, pages like [Pseudo-classes](https://developer.mozilla.org/en-US/docs/Web/CSS/Pseudo-classes) would continue to consistently talk about pseudo-classes as a built-in feature. New documentation would then talk about `state` as a different thing: a custom feature of web components.

This makes it possible to more easily document things like the `:state` pseudo-class itself — which becomes the one bridge between the two concepts. E.g., "The :state CSS pseudo-class selector represents any custom element which currently has the indicated custom state applied." Writing such documentation would likely be harder if the concepts of state and pseudo-class are blurred.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/738#issuecomment-531022901