On Thu, Apr 25, 2024 at 6:14 PM Anders Hartvoll Ruud <andr...@chromium.org> wrote:
> 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. > I saw this morning that WebKit now opposes this proposal <https://github.com/WebKit/standards-positions/issues/337>. Since you phrased this as a condition, should we consider the Intent withdrawn, as the condition is not met? > > 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. > In the WebKit issue <https://github.com/WebKit/standards-positions/issues/337#issuecomment-2072349711>, 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 <https://www.chromium.org/blink/guidelines/web-platform-changes-guidelines/> 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 > <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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKFBnUoz6xu3S_V-N8NiUMtphKmXh1_-4ozaY1WT4Ko0nXLkFg%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/CAM0wra9CgRF15DoaVrcV-9NWQ7BGR%2Bc0Gd3_8-Tyg_sc2M3aSA%40mail.gmail.com.
