Contact emails andr...@chromium.org
Specification https://drafts.csswg.org/css-nesting-1/#nest-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, without explaining how to solve the problems that would arise from that (Issue 9492 <https://github.com/w3c/csswg-drafts/issues/9492>). One promising approach, @nest (proposed by Tab <https://github.com/w3c/csswg-drafts/issues/9492#issuecomment-1779739434:~:text=Add%20a%20new%20%40nest%20rule>), became the basis for my web compat investigation (Doc <https://docs.google.com/document/d/1G7R-Pqk33J8ho3ad-ZpkdBIRvG2xt1ZQwQI_clPlroU/edit?usp=sharing>, @chromium.org), and recently I shared some good news <https://github.com/w3c/csswg-drafts/issues/8738#issuecomment-2048158814> from the use-counters with the CSSWG. This restarted the discussion, and while the CSSWG did agree <https://github.com/w3c/csswg-drafts/issues/8738#issuecomment-2061777236> on the underlying @nest approach, it also basically split people into two camps: 1. @nest should be a web-exposed construct. (Currently specified, per Issue 8738 <https://github.com/w3c/csswg-drafts/issues/8738#issuecomment-2061777236> ). 2. @nest should as much as possible be an implementation detail, unobservable to the author. (Issue 10234 <https://github.com/w3c/csswg-drafts/issues/10234>). The apparent positions so far are that Firefox and Chrome support (1), and Safari (+ other prominent CSSWG members) support (2). At the time of writing, this is where the discussion is now. The CSSWG agrees that addressing the “bare declaration shift” is the most important thing, and also quite urgent, since we don’t know how long the window for making a change here is going to stay open. The expectation <https://github.com/w3c/csswg-drafts/issues/10234#issuecomment-2067746133> of the CSSWG seems to be that browsers first ship @nest as it’s currently specified (1), and then we possibly move towards (2) later. I find this move problematic, since moving to (2) would break the API again, and even if we reasonably believe it will break the API in a much less severe way, it may be hard to actually prove this. Despite this, I have agreed to try to ship @nest, on the condition that we have clear signals from Firefox and Safari that they’ll do the same. I don’t yet have those signals, but I’m sending the intent “early” anyway, to give this issue some visibility. 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.00027%). - Additionally, @nest 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.00017%). Interoperability and Compatibility Gecko: No signal (https://github.com/mozilla/standards-positions/issues/1013) - Emilio seems positive, but the issue is still open. WebKit: No signal (https://github.com/WebKit/standards-positions/issues/337) 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 None 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 M126 Anticipated spec changes Yes, a major one, as explained in the introduction: Issue 10234 <https://github.com/w3c/csswg-drafts/issues/10234>. I am attempting to ship despite this issue, since that’s what the CSSWG wants. Note also: Recently in the above issue, we are now considering a third approach: renaming @nest to something more generic, with the intent to maybe make it more useful in the future, and therefore making its web-exposed presence less annoying. This shows some promise in terms of unifying camps (1) and (2), so we’ll see how this plays out in the next few days. Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5123929441304576?gate=5374099609354240 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/CAKFBnUoz6xu3S_V-N8NiUMtphKmXh1_-4ozaY1WT4Ko0nXLkFg%40mail.gmail.com.
