Add custom state pseudo class

[josepharhar]

This is based on the WICG draft spec here: https://wicg.github.io/custom-state-pseudo-class

Here are some spec issues where this feature has been discussed:
w3ctag/design-reviews#428
w3c/csswg-drafts#4805

Corresponding CSS spec PR: w3c/csswg-drafts#8213

• At least two implementers are interested (and none opposed):
  • Chrome
  • WebKit
• Tests are written and can be reviewed and commented upon at:
  • https://wpt.fyi/results/custom-elements/state
• Implementation bugs are filed:
  • Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=1012098
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1588763
  • WebKit: https://bugs.webkit.org/show_bug.cgi?id=215911
• MDN issue is filed: update docs to reflect new css custom state syntax mdn/content#31258

(See WHATWG Working Mode: Changes for more details.)

---

/custom-elements.html ( diff )
/index.html ( diff )
/infrastructure.html ( diff )
/semantics-other.html ( diff )

[domenic]

Nice work!

[domenic]

To follow existing patterns in the custom elements section, I think we should split this up.

The introduction should go as a new section under https://whatpr.org/html/8467/custom-elements.html#custom-elements-intro . (Maybe "Exposing a custom element's states") And the normative stuff should go as a new section under https://whatpr.org/html/8467/custom-elements.html#element-internals ("Custom pseudo-classes").

[josepharhar]

ok, I tried moving it around. Did i get it right?

[josepharhar]

Weird, the conformance checker is showing errors in the build here but when I run it locally via vnu-jar it doesn't produce any errors...

[domenic]

Looking good!

Weird, the conformance checker is showing errors in the build here but when I run it locally via vnu-jar it doesn't produce any errors...

This is due to whatwg/whatwg.org#401 . Not your fault, don't worry about it, and we'll fix ASAP.

If you're curious, you can probably get the errors to reproduce locally if you update your validator download to the latest release.

[annevk]

Where is the corresponding Selectors PR? And this should probably also reference Selectors for the pseudo-classes?

[josepharhar]

Where is the corresponding Selectors PR? And this should probably also reference Selectors for the pseudo-classes?

There is no PR yet. I'll try to make one next week unless @tabatkins is interested in making one

[josepharhar]

I have created a csswg selectors PR: w3c/csswg-drafts#8213

[domenic]

This LGTM. However note I pushed one fix which is pretty important: I changed the return value of add() to be a DOMString, to match the prose which returns the added value, and also match the requirements for all setlikes.

I can't find any test for the return value of add() in https://wpt.fyi/results/custom-elements/state/tentative/ElementInternals-states.html?label=experimental&label=master&aligned , so please work on adding that (and fixing Chromium, if necessary).

I'm not sure how important it is to land something in selectors, so I'd be happy merging this ASAP. But I guess we haven't fully confirmed second-implementer interest, and @annevk seems concerned about the selectors PR, so I think his sign-off is what is most needed at this point.

[annevk]

It would be good if @tabatkins or @fantasai could have a look. We've had a multitude of issues due to Selectors including something that got then implemented without HTML saying anything about when it matches. I'd rather not add to that.

I also think that the mismatch with ::part() is rather unfortunate as this is supposed to be the psuedo-class counterpart to that. See WebKit/standards-positions#56 for background on that.

[domenic]

We've had a multitude of issues due to Selectors including something that got then implemented without HTML saying anything about when it matches. I'd rather not add to that.

Yeah, but this PR defines the full matching algorithm in HTML. I'm not sure the selectors definitions really add much, given that we have that... they're kind of interesting as a theoretical summary of how a selector might behave in a non-browser user agent, but I think they're less important.

[annevk]

I don't think that's true. Something needs to define that :--blah is not a syntax error. Currently :root, :--blah { background:lime } is thrown out.

[rniwa]

This feature will only work with custom elements. That seems different from "customness" of CSS variables / properties. Custom CSS variables and properties aren't things that custom elements define but rather what a page author uses across multiple (custom or not) elements to stylize their web page. To mirror this, custom pseudo class should be something author can define on any element independent of custom elements for the use in their own web pages. For example, maybe we want :--happpy pseudo class to indicate happy images of cats. No reason why img or picture element needs to be wrapped in a custom element just to support this custom pseudo state. Yet we also want a state API for custom elements with good encapsulation as well. I believe :state is the right syntax for such a feature for custom elements as it nicely mirrors ::part. :--state should be reserved for future addition of more generic version of custom pseudo class (e.g. Element.prototype.customPseudo) that can be defined outside of web components.

[annevk]

(I won't be able to attend the meeting anytime soon, but it would be good to get the above feedback addressed.)

[emilio]

I tend to agree that the restriction to custom elements feels arbitrary. I don't have strong opinions on the syntax tho.

[josepharhar]

I believe :state is the right syntax for such a feature for custom elements as it nicely mirrors ::part. :--state should be reserved for future addition of more generic version of custom pseudo class (e.g. Element.prototype.customPseudo) that can be defined outside of web components.

So if I wanted to define a custom pseudo class "foo" are you saying it should be like :state(foo)? And that we should just rename :--foo to :state(foo) and continue with this feature?

[rniwa]

I believe :state is the right syntax for such a feature for custom elements as it nicely mirrors ::part. :--state should be reserved for future addition of more generic version of custom pseudo class (e.g. Element.prototype.customPseudo) that can be defined outside of web components.

So if I wanted to define a custom pseudo class "foo" are you saying it should be like :state(foo)? And that we should just rename :--foo to :state(foo) and continue with this feature?

Yes. That's more consistent with :part feature for web components.

[jyasskin]

Sorry for the drive-by review, but is this the right formatting for a :state(arg) pseudo-class? I see why it happened while the pseudo-class was spelled :--arg, but once it's formatted as a function call like :dir(ltr), I'd expect something like <dfn selector noexport><code data-x="selector-state">:state(<var>identifier</var>)</code></dfn></dt>.

[josepharhar]

This is much easier to read, so I did it. Thanks!

[keithamus]

I'm curious about invalid states, and how they're approached. Right now Chrome's implementation checks that a string begins -- which I imagine will be relaxed. The existing WPTs (via idl tests) also check for a missing argument. But should there be additional validation of the given string? No validation allows for stuff like:

.states.set('@foo')
 // `:state(@foo)` is an invalid selector (at-keyword)
 // `:state(\@foo)` will match.

.states.set('1rem')
 // `:state(1rem)` is an invalid selector (dimension)
 // `:state(\1rem)` won't match
 // `:state(\31rem)` will match (a unicode escape sequence).

.states.set('.foo')
 // `:state(.foo)` is an invalid selector (delim + ident)
 // `:state(\.foo)` will match.

Maybe these are fine? I imagine some will be a little surprising to users. Having both JS and CSS silently fail could make this difficult to debug.

I also think no validation creates a discrepancy with .matches() given the above. so .states.set('@foo') won't throw but .matches(':state(@foo)') will.

[annevk]

But matches(':state(\@foo)') won't, right? This seems fine and on par with how IDs and class names work.

[josepharhar]

Yeah I'm not sure if it would be easy or not for us to sort of run css parsing on the string passed in as if it were used inside :state() to find out if it would match or not.

Having both JS and CSS silently fail could make this difficult to debug.

imo, the silent failing of CSS selector parsing is always going to be hard. We had a bug in chrome recently because a CSS selector in the user agent stylesheet was invalid and nobody noticed 😅

[keithamus]

FWIW classList, being a DOMTokenList, checks for empty strings and spaces. Right now Chrome's implementation of CustomStateSet (which uses dashed idents and not :state()) expects a <dashed-ident> production and checks each character is a valid name code point: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/html/custom/custom_state_set.cc;l=63-72;drc=abbfc06e9b070c9ea64af2b233624646cef00252?q=customstateset&ss=chromium%2Fchromium%2Fsrc.

[annevk]

The reason classList does that is because it's a space-separated list. If it didn't check that you'd run into serialization issues. The empty string check I'm less sure about. getElementById() doesn't throw for an empty string, it just results in a non-match. Following that seems better.

[keithamus]

This is in Firefox 122 [tracking issue] behind the dom.element.customstateset.enabled flag, and in WebKit's main branch, under the CustomStateSetEnabled flag. Both use the :state() syntax. There's also fairly good coverage in WPT including some robust parser tests, and api tests.

[josepharhar]

Thanks @keithamus !!!
Is there anything else I can do to get this merged? I can file an MDN issue if we are confident that this will get shipped as specced in this PR.

[lukewarlow]

WebKit now has this shipped by default on the main branch. Just as an fyi. Firefox appears to need some style invalidation work doing but is otherwise following this new spec (from what I can tell)

[annevk]

Thanks @josepharhar for making this feature happen and thanks @keithamus for providing the implementation needed to get this over the finish line!

(Just noticed I forgot to leave this comment when I merged.)