CSS Custom State

[josepharhar]

This was split from #181

Description & Rationale

https:/WICG/custom-state-pseudo-class/blob/main/explainer.md
Built-in elements have certain “states” that can change over time depending on user interaction and other factors, and are exposed to web authors through pseudo classes. For example, some form controls have the “invalid” state, which is exposed through the :invalid pseudo class.

Like built-in elements, custom elements can have various states to be in too, and web authors might want to expose these states in a similar fashion as the built-in elements. With the proposed states property on ElementInternals, custom element authors can add and modify custom states for the custom elements, and allow them to be selected with the :state() selector.

Tests

https://wpt.fyi/results/custom-elements/state

Spec

https://wicg.github.io/custom-state-pseudo-class/

[jgraham]

Is it expected for this spec to be on a standards track by the EoY?

[josepharhar]

I'm not sure if anybody has put it on the standards track since the referenced wicg spec was written 2 years ago. I will try to get it on the standards track myself.

[foolip]

@jgraham and other reviewers, assuming for now everything else about this proposal looks good, could we do a conditional inclusion in Interop 2023, where if it's not on a standards track by EOY we exclude it?

[jgraham]

I don't have concerns about that from a process point of view. But the standards track requirement isn't just a formaility; things that aren't already on a standards track probably had less multi-vendor review and are more likely to have concerns around the stability of the spec. So, without knowing any specifics of this proposal/spec, I'd still say that in general it's less likely that things not yet on a standards track are going to be accepted.

[josepharhar]

I found a csswg issue where there has been some discussion: w3c/csswg-drafts#4805
I'll try to get things moving in that thread again. Does this qualify as standards track?

[foolip]

@josepharhar the definition we used in the focus area proposal template was:

The feature should be defined by a standards-track specification from the following organizations:

• IETF (Standard Track)
• Khronos Group
• TC39 (Stage 2+)
• W3C (Recommendation Track)
• WHATWG

So in this case it would mean that the changes are merged into https://drafts.csswg.org/selectors/, not just an open issue for discussion. How much work would it be to turn https://wicg.github.io/custom-state-pseudo-class/ into a pull request for that spec and get it reviewed/merged?

[josepharhar]

I have turned it into a pull request: whatwg/html#8467

[foolip]

In the MDN short survey on APIs & JavaScript, "Web Components (custom elements, Shadow DOM, etc.)" was the most popular choice by a fairly wide margin, selected by ~39% of survey takers.

Web Components was split into many granular proposals, and the survey results don't tell us which aspects web developers want the most, but it's fair to say that something about Web Components is important. (I'm posting this comment on each of the split proposals.)

[nairnandu]

Thank you for proposing CSS Custom State for inclusion in Interop 2023.

We wanted to let you know that this proposal was not selected to be part of Interop this year. As discussed in the issue, the proposal was not on a standards track at the time of proposal selection. This made it unsuitable for inclusion in Interop 2023. However this should not be taken as a comment on the technology as a whole, and if the feature is standardized we would welcome this proposal being resubmitted for a future round of Interop.

For an overview of our process, see the proposal selection summary. Thank you again for contributing to Interop 2023!

Posted on behalf of the Interop team.