You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on May 28, 2024. It is now read-only.
The point of the state pseudoclass is to expose a class-like semantic via a pseudoclass. It's currently "namespaced" under the :state() function to avoid collisions with other pseudoclass names. However, the way we've avoided such clashes in other places in CSS is by just using the --ident pattern, which is by convention reserved solely for author-defined names.
Peter suggests that it would thus be more natural to expose this feature with that syntax, so that instead of :state(foo), you'd write :--foo. I agree with this!
It makes the feature mesh more naturally with the existing platform, so custom elements can expose their own pseudoclasses in a way that feels real.
It seems to extend to non-boolean states more naturally; you'd write such things as :--foo(bar), exactly like the non-boolean UA pseudo-classes, rather than the imo less readable :state(foo bar), or a novel syntax like :state(foo = bar).
A practical consequence of this is that we'd need to add a check to the .add() and .toggle() methods to ensure that the token being set starts with a "--", so we can throw otherwise. (This is the standard practice in similar APIs, to ensure a close concordance between all uses of the identifier, rather than accepting anything and implicitly prepending a "--" for CSS use.)
I believe the parsing difficulty is similar, but I'm not familiar with the impl details.
This was raised by @plinss in the CSSWG discussion last week.
The point of the state pseudoclass is to expose a class-like semantic via a pseudoclass. It's currently "namespaced" under the
:state()function to avoid collisions with other pseudoclass names. However, the way we've avoided such clashes in other places in CSS is by just using the --ident pattern, which is by convention reserved solely for author-defined names.Peter suggests that it would thus be more natural to expose this feature with that syntax, so that instead of
:state(foo), you'd write:--foo. I agree with this!:--foo(bar), exactly like the non-boolean UA pseudo-classes, rather than the imo less readable:state(foo bar), or a novel syntax like:state(foo = bar).A practical consequence of this is that we'd need to add a check to the .add() and .toggle() methods to ensure that the token being set starts with a "--", so we can throw otherwise. (This is the standard practice in similar APIs, to ensure a close concordance between all uses of the identifier, rather than accepting anything and implicitly prepending a "--" for CSS use.)
I believe the parsing difficulty is similar, but I'm not familiar with the impl details.