Intent to Ship: The Nested Declarations Rule
Anders Hartvoll Ruud
Note: See also the previous (failed) intent for @nest. All CSSWG disagreements around this are now resolved.
Contact emails
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), and the CSSWG now consider the decision a mistake. In October 2023, the CSSWG resolved to not do the shifting behavior anymore, and after a long debate on how to handle the implications of this (Issue 10234), the CSSWG finally resolved to introduce the CSSNestedDeclarations rule to solve the problem.
Blink component
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 (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 (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.
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 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?
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 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.
Daniel Clark
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
--
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+...@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.
Anders Hartvoll Ruud
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?
Philip Jägenstedt
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.
Yoav Weiss (@Shopify)
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.
Chris Harrelson
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohS%2BCJx6o%3D8OCQPgqi10wqpg3GQ2-ziCO00jx0QPvpvC36w%40mail.gmail.com.
Yoav Weiss (@Shopify)
Anders Hartvoll Ruud
Can you flip the "testing" bit in the chromestatus entry? (and mark it with "n/a" if that's the case)
Anders Hartvoll Ruud
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.