+1 on the API owners discussing this. I'd like to understand better how we wound up shipping :--foo and then having the CSSWG ask us to change it to :state(foo) instead, and what we could do in the future to avoid it happening again.
It looks like the initial proposal was :state(foo); the CSSWG asked to change it to :--foo in 2020 <https://github.com/w3c/csswg-drafts/issues/4805#issuecomment-591547956>; we shipped that in M90 in 2021 <https://chromestatus.com/feature/6537562418053120> (with a feature entry that still says :state 🙃); then Ryosuke suggested undoing that change in January 2023 <https://github.com/whatwg/html/pull/8467#issuecomment-1381645661>, and the CSSWG accepted that suggestion in August <https://github.com/w3c/csswg-drafts/issues/4805#issuecomment-1663111980>. As far as I can see, nobody asked for the ergonomic evidence that https://www.chromium.org/blink/guidelines/web-platform-changes-guidelines/#browser-engine-reviews says we can expect after Chrome has shipped a feature. It doesn't seem like this feature was so contentious that the team needed to use a name change as a bargaining chip, so we should probably have insisted on more evidence before agreeing with the change. Maybe that's still a "should" instead of a "should have": Joey's second email <https://groups.google.com/a/chromium.org/g/blink-dev/c/JvpHoUfhJYE/m/wPAHJzIvAQAJ> might say that the CSSWG's resolution <https://github.com/w3c/csswg-drafts/issues/4805#issuecomment-1663111980> about this isn't as committed as it appears to an external observer? Should we generally hold off on shipping CSS features until they land in an official draft, or even in a CR? Should we be clearer to the CSSWG when we decide to ship ahead of their consensus that the bar for changes is going up? There's not good support for this kind of per-WG restriction in Chrome Status yet, but maybe it'll fit near https://github.com/GoogleChrome/chromium-dashboard/issues/3390... Jeffrey On Fri, Sep 29, 2023 at 12:32 PM Alex Russell <slightly...@chromium.org> wrote: > hrm, this is another instance of bikeshedding after shipping, and I'm not > inclined to approve. Perhaps we can discuss at next week's API OWNERs > meeting? > > Adding others who I know are interested in this topic. > > On Friday, September 29, 2023 at 9:16:13 AM UTC-7 Joey Arhar wrote: > >> The spec for the new syntax hasn't been merged yet, I haven't finished >> implementing it in chromium yet, and I don't have estimated milestones yet, >> but I'd like to get the API owners thoughts on whether this deprecation >> would be acceptable to help guide the spec discussion. >> >> I did some analysis of the top 8 websites on the chromestatus entry to >> see what the breakage would be like: >> https://docs.google.com/document/d/1BHoO12ts0E-NQQH9AMwR2sKAIV0OPB-FA_8QXMpolz0/edit?usp=sharing >> I found that most of them had the affected custom elements behind >> display:none rules that I had to manually remove in order to use them. >> There was only one website where there was actual breakage by default, in >> which case the carousel buttons didn't work on firefox and safari. If the >> new syntax is just for the CSS property and we keep CustomStateSet the >> same, then the affected website's buttons would continue to work but >> whatever custom styles they have (which I couldn't trigger) wouldn't apply >> anymore. >> >> Personally, I think that this breakage would not be bad especially if we >> keep CustomStateSet the same, and I kind of like :state(foo) more than >> :--foo. However, I might have not made it clear in the spec discussions yet >> that we have already shipped :--foo by default for several years. >> >> On Fri, Sep 29, 2023 at 9:15 AM Joey Arhar <jar...@chromium.org> wrote: >> >>> Contact emailsjar...@chromium.org >>> >>> ExplainerNone >>> >>> Specificationhttps://github.com/whatwg/html/pull/8467 >>> >>> Summary >>> >>> CSS custom state, which allows custom elements to expose their own >>> pseudo-classes, was shipped here: >>> https://groups.google.com/a/chromium.org/g/blink-dev/c/dJibhmzE73o/m/VT-NceIhAAAJ >>> >>> This feature has not been implemented in gecko or webkit yet. I recently >>> made an effort to spec this feature in CSSWG and WHATWG, but there was >>> pushback to change the syntax back from :--foo to :state(foo), and the >>> CSSWG has resolved to do this as well: >>> https://github.com/w3c/csswg-drafts/issues/4805 >>> >>> The UseCounter is currently at 0.03% >>> https://chromestatus.com/metrics/feature/timeline/popularity/3796 >>> >>> This deprecation will have a window where we support both the old syntax >>> and the new syntax so websites can switch to the new one. >>> >>> >>> Blink componentBlink>HTML>CustomElements >>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EHTML%3ECustomElements> >>> >>> TAG reviewNone >>> >>> TAG review statusNot 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*: No signal >>> >>> *WebKit*: No signal ( >>> https://github.com/whatwg/html/pull/8467#issuecomment-1381645661) >>> >>> *Web developers*: No signals >>> >>> *Other signals*: >>> >>> Activation >>> >>> Switching to the new syntax should be quite 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 >>> >>> >>> Will this feature be supported on all six Blink platforms (Windows, Mac, >>> Linux, Chrome OS, Android, and Android WebView)?Yes >>> >>> Is this feature fully tested by web-platform-tests >>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>> ?Yes >>> >>> Flag name on chrome://flagsNone >>> >>> Finch feature nameNone >>> >>> Non-finch justificationNone >>> >>> Requires code in //chrome?False >>> >>> Estimated milestones >>> >>> No milestones specified >>> >>> >>> Anticipated spec changes >>> >>> Open questions about a feature may be a source of future web compat or >>> interop issues. Please list open issues (e.g. links to known github issues >>> in the project for the feature specification) whose resolution may >>> introduce web compat/interop risk (e.g., changing to naming or structure of >>> the API in a non-backward-compatible way). >>> None >>> >>> Link to entry on the Chrome Platform Status >>> https://chromestatus.com/feature/5140610730426368 >>> >>> This intent message was generated by Chrome Platform Status >>> <https://chromestatus.com/>. >>> >> -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANh-dXnvT4DeG%2BLg4WPpM2zptH-ObOTSjsB2eGNd9FWmyjeMoQ%40mail.gmail.com.
