On Friday, September 29, 2023 at 9:32:16 PM UTC+2 Alex Russell 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? We should definitely discuss this broader subject! 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/docume nt/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. Have Firefox and Safari implemented the new syntax? 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. 0.03% is not nothing. 1/8 ratio of breakage there is encouraging, but we'd probably need slightly broader sampling approach to get a sense of real-life breakage. (e.g. ~20 random sites) 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/ch romium.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-d rafts/issues/4805 The UseCounter is currently at 0.03% https://chromestatus.com/metri cs/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/htm l/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 Statushttps://chromestatus.com/featu re/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/1894e463-57e8-48d2-8359-e6261fdeda74n%40chromium.org.
