Intent to Ship: Stable Bare Declarations (@nest)
Anders Hartvoll Ruud
Contact emails
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), and the CSSWG now consider the decision a mistake. In October 2023, the CSSWG resolved to not do the shifting behavior anymore, without explaining how to solve the problems that would arise from that (Issue 9492).
One promising approach, @nest (proposed by Tab), became the basis for my web compat investigation (Doc, @chromium.org), and recently I shared some good news from the use-counters with the CSSWG. This restarted the discussion, and while the CSSWG did agree on the underlying @nest approach, it also basically split people into two camps:
@nest should be a web-exposed construct. (Currently specified, per Issue 8738).
@nest should as much as possible be an implementation detail, unobservable to the author. (Issue 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 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
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.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 (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?
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.
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.
Domenic Denicola
@nest
👿 It does solve the immediate CSS Nesting issue, and the lack of
interop will force a resolution sooner rather than later, instead of
letting inertia take over. Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5123929441304576?gate=5374099609354240
This intent message was generated by Chrome Platform Status.
--
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/CAKFBnUoz6xu3S_V-N8NiUMtphKmXh1_-4ozaY1WT4Ko0nXLkFg%40mail.gmail.com.
Mike Taylor
+1 to this, but can you also explain why you think it's a good idea to ship, despite finding the proposal problematic?
Anticipated spec changes
Yes, a major one, as explained in the introduction: Issue 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.
In the WebKit issue, a CSSWG Invited Expert adds context by saying
> perhaps a way to guarantee that the current proposal will not become a de facto standard is to simply implement a non author-facing@nest👿 It does solve the immediate CSS Nesting issue, and the lack of interop will force a resolution sooner rather than later, instead of letting inertia take over.
This doesn't seem like an appropriate use of the Blink process. Exposing our users to a non-interoperable situation in order to overcome inertia or disagreement within a standards-body is against the values that guide shipping approvals.
Anders Hartvoll Ruud
Yes, consider it withdrawn. I am happy with this outcome for now.
Yes, I also had a negative reaction to that comment.
This doesn't seem like an appropriate use of the Blink process. Exposing our users to a non-interoperable situation in order to overcome inertia or disagreement within a standards-body is against the values that guide shipping approvals.
That is not what this is.
- The CSSWG, both camps (1) and (2), agreed to add @nest to the spec.
- I initially thought it obvious that Issue 10234 would block carrying out @nest in practice.
- But then prominent CSSWG members clarified that, no, it should not block.
- Lacking any objection from camp (2) on the above comments, I reluctantly agreed to try and carry out what was the apparent agreement within the standards body.
I welcome corrections if I've misunderstood that comment, or more perspective if you have it to give.
The problem here is that the clock is ticking, and everyone (CSSWG) agrees that inaction is probably the worst outcome. It could lead to Issue 8738 not being addressed at all, in which case we'd have interop, but on an API which is now seen as a mistake. Or the outcome that worries me the most: some browser ships something @nest-like, but we do nothing, and we end up with a very bad interop issue vs. shipping @nest with Issue 10234 still open. So really I was just trying to ensure that our users aren't exposed to the worst non-interoperable situation that can arise from this.
> +1 to this, but can you also explain why you think it's a good idea to ship, despite finding the proposal problematic?
I don't find the proposal problematic (what is specified now looks good), but I'm not comfortable shipping with Issue 10234 still open. But for reasons explained above, doing nothing makes me equally uncomfortable, especially if the other browsers had intended to ship @nest.But with WebKit's opposition now crystal clear, I think we should just do nothing for now.Thanks for the feedback Domenic and Mike.
PhistucK
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKFBnUou98dbsCej%3Dji3AgL7-esjCzvnYUByA6hG6PKzZ2vdQw%40mail.gmail.com.