The stated answer to "Will this feature be supported on all six Blink platforms" is "No", but I'd expect this to be the same on all platforms - is that right?
Could you elaborate a bit on why this might not be doable behind a flag? -- Dan From: Anders Hartvoll Ruud <andr...@chromium.org> Sent: Thursday, August 1, 2024 4:14 AM To: blink-dev <blink-dev@chromium.org> Subject: [blink-dev] Intent to Ship: The Nested Declarations Rule Note: See also the previous (failed) intent<https://groups.google.com/a/chromium.org/g/blink-dev/c/prg4CN0eEGg> for @nest. All CSSWG disagreements around this are now resolved. Contact emails andr...@chromium.org<mailto:andr...@chromium.org> Specification https://drafts.csswg.org/css-nesting-1/#nested-declarations-rule Summary CSS Nesting initially shipped with an interesting quirk that would cause bare declarations that come after a nested rule to "shift", for example: .foo { width: 100px; height: 100px; @media screen { background-color: red; } background-color: green; } You would think that the background-color of <div class=foo> would be green here, but no, that declaration is shifted up to the main (leading) block of declarations during parsing: .foo { width: 100px; height: 100px; background-color: green; /* I'm here now */ @media screen { background-color: red; } } This was at the time done intentionally for a mix of CSSOM and historical reasons, and all implementations of CSS Nesting currently agree on this behavior. However, it turns out this shifting behavior isn't what authors expect (WebKit blog post<https://webkit.org/blog/14571/css-nesting-and-the-cascade/#:~:text=an%20element%20selector.-,Another%20question,-There%20is%20one>), and the CSSWG now consider the decision a mistake. In October 2023, the CSSWG resolved<https://github.com/w3c/csswg-drafts/issues/8738#issuecomment-1768977689> to not do the shifting behavior anymore, and after a long debate on how to handle the implications of this (Issue 10234<https://github.com/w3c/csswg-drafts/issues/10234>), the CSSWG finally resolved to introduce the CSSNestedDeclarations rule to solve the problem. Blink component Blink>CSS<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS> TAG review None TAG review status Not applicable Risks This intent is a breaking change, with two main points of breakage: * Keeping the bare declarations in place can affect the winner of the cascade (the example in the introduction). This is covered by CSSBareDeclarationShift<https://chromestatus.com/metrics/feature/timeline/popularity/4783> (0.00042%). * Additionally, CSSNestingDeclarations will have different specificity behavior for nested group rules, and this can also affect the winner of the cascade. This is covered by CSSNestedGroupRuleSpecificity<https://chromestatus.com/metrics/feature/timeline/popularity/4784> (0.00046%). Interoperability and Compatibility Gecko: No signal (https://github.com/mozilla/standards-positions/issues/1048) - "looks acceptable to me". Note that the issue Emilio mentions in his feedback has been resolved<https://github.com/w3c/csswg-drafts/issues/10520>. WebKit: No signal on the position itself (https://github.com/WebKit/standards-positions/issues/369) - It's however slightly ridiculous to request a signal in this case, since this Intent carries out WebKit's proposal<https://github.com/w3c/csswg-drafts/issues/10234#issuecomment-2137832089> exactly. Web developers: No signals Other signals: 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 We should be able to reuse the existing inspector feature for nested style rules. Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)? No Is this feature fully tested by web-platform-tests<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>? Not yet. Flag name on chrome://flags None Finch feature name None (yet). I'm not yet sure whether or not this change can be done behind a flag. Non-finch justification None Requires code in //chrome? False Estimated milestones M129 Anticipated spec changes None. The last blocking issue<https://github.com/w3c/csswg-drafts/issues/10520> was closed this week. Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5084403030818816?gate=5133271437148160 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<mailto:blink-dev+unsubscr...@chromium.org>. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKFBnUr%3D6F_H29JYk8C79ZnU5LdPgSuF239LYnnYmgxfrk3sGA%40mail.gmail.com<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKFBnUr%3D6F_H29JYk8C79ZnU5LdPgSuF239LYnnYmgxfrk3sGA%40mail.gmail.com?utm_medium=email&utm_source=footer>. -- 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/SA1PR00MB1438C61AD0E2A0F395290DC5C5B22%40SA1PR00MB1438.namprd00.prod.outlook.com.
