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
The syntax of this feature needs to change in order to get support from the other browsers and eventually have interoperable behavior.
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.
Switching to the new syntax is easy.
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
None
https://wpt.fyi/results/custom-elements/state
No milestones specified
--
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.
> Do you know what the breakage looks likeI 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 syntaxWebsites 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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwLgrD%3DJp9F%2Bn0yw5HjYFyM3k0NckpuXZn%3DjA3Fri8L9Rw%40mail.gmail.com.
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
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2POX7A_BH14CXttoB9oj6EoQy4j%2BpXoK1fFLNU-bh8Lfg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwKiLLiyi7gSo1Y%2BiMzkkFhw5b34kzjExV7yQcjF_uy5Vw%40mail.gmail.com.
LGTM3, and +1 to Yoav's suggestion.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohS%2BNyXUdQg2F%2B_n%3DRC8xv_o7D2PWF121Uj1uTbm0RjEC2Q%40mail.gmail.com.