Intent to Ship: Stable Bare Declarations (@nest)

330 views
Skip to first unread message

Anders Hartvoll Ruud

unread,
Apr 25, 2024, 5:14:48 AMApr 25
to blink-dev

Contact emails

and...@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), 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:


  1. @nest should be a web-exposed construct. (Currently specified, per Issue 8738). 

  2. @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

Blink>CSS


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

unread,
Apr 25, 2024, 10:10:06 PMApr 25
to Anders Hartvoll Ruud, blink-dev
I saw this morning that WebKit now opposes this proposal. Since you phrased this as a condition, should we consider the Intent withdrawn, as the condition is not met?
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.

I welcome corrections if I've misunderstood that comment, or more perspective if you have it to give.
 

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

unread,
Apr 26, 2024, 1:13:18 AMApr 26
to Domenic Denicola, Anders Hartvoll Ruud, blink-dev

+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.
Strong agree here.

Anders Hartvoll Ruud

unread,
Apr 27, 2024, 3:31:04 AMApr 27
to Domenic Denicola, blink-dev
Oops, I intended to send that e-mail to the list, must have hit "Reply" instead of "Reply All".

On Fri, Apr 26, 2024 at 10:45 AM Anders Hartvoll Ruud <and...@chromium.org> wrote:


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

unread,
Apr 30, 2024, 9:42:33 AMApr 30
to Anders Hartvoll Ruud, Domenic Denicola, blink-dev
So we are back to the worst possible outcome? :(

PhistucK


Reply all
Reply to author
Forward
0 new messages