LGTM1, this is important to do sooner rather than later, so that the current behavior is not locked in by site compat. Thank you for finding a solution that's acceptable to everyone!
Given that this was discussed extensively in the CSSWG, I don't think we need to wait further on vendor positions. On Fri, Aug 2, 2024 at 11:06 AM Anders Hartvoll Ruud <andr...@chromium.org> wrote: > On Fri, Aug 2, 2024 at 1:54 AM Daniel Clark <dan...@microsoft.com> wrote: > >> 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? >> > > Yes, that was a mistake. > > >> >> >> Could you elaborate a bit on why this might not be doable behind a flag? >> >> >> > > This comment was ... "inherited" from the previous version of this intent ( > https://groups.google.com/a/chromium.org/g/blink-dev/c/prg4CN0eEGg?pli=1). > Looking a bit closer at CSSParserImpl now, it seems doable. We can proceed > as if this will have a flag. I'll post the flag name to this thread before > shipping. > > >> -- 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 >> >> >> 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. >> 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/CAKFBnUqTETTPT1whp_E35GeyjzxmsRrrWNg8HptPVD1_J74qgQ%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKFBnUqTETTPT1whp_E35GeyjzxmsRrrWNg8HptPVD1_J74qgQ%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/CAARdPYc4KOp51E9UEeM%3DLepctuWvi-SMPS6AKF0_-6kURSSGpQ%40mail.gmail.com.
