Intent to Deprecate and Remove: Deprecate old CSS custom state syntax

360 views
Skip to first unread message

Joey Arhar

unread,
May 21, 2024, 1:39:47 PMMay 21
to blink-dev

Contact emails

jar...@chromium.org

Explainer

None

Specification

https://github.com/whatwg/html/pull/8467

Summary

The CSS custom state pseudo-class is being renamed from :--foo to :state(foo). The new syntax, :state(foo), has been enabled by default, and now we have to deprecate and remove the :--foo syntax. Gecko and webkit never implemented the old syntax and they have both shipped the new syntax. We are currently shipping both the new syntax and the old syntax at the same time. There have been console errors and DevTools deprecations for the old syntax for many milestones already. Previous thread on this topic: https://groups.google.com/a/chromium.org/g/blink-dev/c/JvpHoUfhJYE/m/uRtWiqoHAQAJ The UseCounter is currently at 0.04% https://chromestatus.com/metrics/feature/timeline/popularity/3796



Blink component

Blink>HTML>CustomElements

Motivation

The syntax of this feature needs to change in order to get support from the other browsers and eventually have interoperable behavior.



Initial public proposal

None

TAG review

None

TAG review status

Not applicable

Risks



Interoperability and Compatibility

Websites which are currently using the old syntax and don't migrate to the new syntax will have CSS selectors which become invalid which would impact the styling of their custom elements.



Gecko: Positive Firefox has shipped the new syntax

WebKit: Positive (https://github.com/whatwg/html/pull/8467#issuecomment-1381645661) Safari has shipped the new syntax

Web developers: No signals

Other signals:

Activation

Switching to the new syntax is easy.



WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None



Debuggability

None



Is this feature fully tested by web-platform-tests?

Yes

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



Flag name on chrome://flags

None

Finch feature name

CSSCustomStateDeprecatedSyntax

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/issues/41486953

Estimated milestones

No milestones specified



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5140610730426368?gate=4940354997714944

Links to previous Intent discussions

https://groups.google.com/a/chromium.org/g/blink-dev/c/JvpHoUfhJYE/m/uRtWiqoHAQAJ

This intent message was generated by Chrome Platform Status.

Vladimir Levin

unread,
May 21, 2024, 2:09:48 PMMay 21
to Joey Arhar, blink-dev
Hey,

0.04% seems like a fairly sizable number. Do you know what the breakage looks like or whether this usage is limited to a library/a small set of large websites or something else?

Ideally, this is feature detected with some fallback syntax


--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwKTMe%3DDOHsX%2Bs6PH%2BO6w0sJ7ZtS6jL%2BGV%2B958ZXLux_Ew%40mail.gmail.com.

Joey Arhar

unread,
May 21, 2024, 2:20:35 PMMay 21
to Vladimir Levin, blink-dev
> Do you know what the breakage looks like

I pushed to make sure that using the old syntax with CustomStateSet.add() wouldn't throw exceptions when in the new mode in order to reduce breakage. When websites use the old syntax after it's removed, they will just have styling differences because their selectors won't parse anymore.

> or whether this usage is limited to a library/a small set of large websites or something else?

Based on the analysis that I linked in the previous thread, there are some websites which all look very similar which use it, but they are all hidden behind display:none elements that I had to manually reveal. There was only one website I found which was actually using it which has a carousel which has buttons that didn't work in safari and firefox because CustomStateSet didn't exist yet.

I don't think there is a popular library which is using the deprecated syntax.

> Ideally, this is feature detected with some fallback syntax

Websites just have to replace ":--foo" with ":state(foo)", I don't think any feature detection is necessary. If they are interested in supporting older browsers, then I don't see why they would have any interest in looking at whether the deprecated syntax works or not because the other browsers didn't have it before and neither did we until a couple years ago.

Vladimir Levin

unread,
May 22, 2024, 12:04:21 PMMay 22
to Joey Arhar, blink-dev
On Tue, May 21, 2024 at 2:20 PM Joey Arhar <jar...@chromium.org> wrote:
> Do you know what the breakage looks like

I pushed to make sure that using the old syntax with CustomStateSet.add() wouldn't throw exceptions when in the new mode in order to reduce breakage. When websites use the old syntax after it's removed, they will just have styling differences because their selectors won't parse anymore.

> or whether this usage is limited to a library/a small set of large websites or something else?

Based on the analysis that I linked in the previous thread, there are some websites which all look very similar which use it, but they are all hidden behind display:none elements that I had to manually reveal. There was only one website I found which was actually using it which has a carousel which has buttons that didn't work in safari and firefox because CustomStateSet didn't exist yet.

I don't think there is a popular library which is using the deprecated syntax.

> Ideally, this is feature detected with some fallback syntax

Websites just have to replace ":--foo" with ":state(foo)", I don't think any feature detection is necessary. If they are interested in supporting older browsers, then I don't see why they would have any interest in looking at whether the deprecated syntax works or not because the other browsers didn't have it before and neither did we until a couple years ago.

I meant I hope that existing use is either feature-detected or it's using both properties. In either case, it's very easy to fix if problems arise since alternate syntax is shipped already in multiple browsers.

LGTM1

Daniel Bratell

unread,
May 22, 2024, 12:22:51 PMMay 22
to Vladimir Levin, Joey Arhar, blink-dev

To be particular about the usage number, it's about a magnitude more than our informal limit. That doesn't mean it can't be shipped, but it means that we want to be fairly certain that >90% of the users are unaffected by the change.

How should I interpret the results from your investigation? That none of the 8 investigated sites would be negatively affected?

/Daniel

Joey Arhar

unread,
May 28, 2024, 4:33:45 PMMay 28
to Daniel Bratell, Vladimir Levin, blink-dev
> How should I interpret the results from your investigation? That none of the 8 investigated sites would be negatively affected?

There is only one site which is actually affected: https://resolv.com.br/
The buttons in the carousel there won't light up anymore, but they will still work. I made sure of that based on the shape of the JS portion of the new syntax. You can test this out in firefox nightly or safari TP.

Yoav Weiss (@Shopify)

unread,
May 29, 2024, 1:00:55 AMMay 29
to Joey Arhar, Daniel Bratell, Vladimir Levin, blink-dev
LGTM2

Please make sure that use of the old syntax triggers some kind of developer-facing warning, so that it won't be too hard to catch the cause for the behavior change in the few sites that will be affected.

Mike Taylor

unread,
May 29, 2024, 9:47:38 AMMay 29
to Yoav Weiss (@Shopify), Joey Arhar, Daniel Bratell, Vladimir Levin, blink-dev

Joey Arhar

unread,
May 29, 2024, 12:13:11 PMMay 29
to Mike Taylor, Yoav Weiss (@Shopify), Daniel Bratell, Vladimir Levin, blink-dev
> Please make sure that use of the old syntax triggers some kind of developer-facing warning, so that it won't be too hard to catch the cause for the behavior change in the few sites that will be affected.

Sounds good, I will keep the existing console message in there, at least for a while.
Reply all
Reply to author
Forward
0 new messages