(Don't) Allow any element to use :state(), not just custom elements

[tabatkins]

This was raised by @plinss in the CSSWG discussion last week.

Peter suggests that there's no particularly good reason to restrict this to only custom elements, and it should be made available to all elements.

I strongly disagree, and think we should resolve to not do this.

First, :state() is semantically identical to using classes. :state(foo) and .foo convey precisely the same semantics. Arbitrary elements already have the ability to use classes, so why go to special effort to give them another way to express class semantics? It would just result in confusion over which is the better thing to use.

So then, why offer :state() at all? Can't custom elements just use class as well? No. ^_^

Look back at the justification for UA-defined pseudo-classes. All the boolean ones, at least, are also exactly equivalent, semantically, to classes. Why do they have a different syntax, then? It's because we want to avoid name clashes, which result in accidental over-styling. An author might legitimately use a class like "invalid" for purposes unrelated to an input's :invalid state, and it would be bad for the .invalid styles to apply to random inputs they weren't expecting.

Same here. Authors using custom elements they didn't author have no guarantee about what states the custom elements are going to expose. Even if they do study the documentation, the states are still defined by the custom element rather than the author, which means that adding a new custom element to the page might introduce a clash and require the author to either 🅐 edit the source code of the custom element to use a different class, or 🅑 switch the classes they're using on the page to something non-clashing. :state() sidesteps the entire issue by putting the class-like thing in a unique namespace that can't clash with classes (or, for that matter, UA pseudo-classes).

There's also the more general problem of custom elements "sprouting" attributes that the page author didn't put there; this is a footgun. We try hard to avoid that, doing things like exposing a11y apis directly even if they could be done by just self-adding some ARIA attributes. Similarly, then, we don't want a custom element to add or mutate the class attribute on itself; that's API for the page author, not for the element.

So, I think we should reject this feedback, and continue to limit this to being a custom-element API.

[plinss]

I believe it was Emilio that raised this point, not me. I also agree that this should be restricted to custom elements at this time.

[chrishtr]

I agree. Let's close this issue.

[tabatkins]

Sounds good.