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 <andr...@chromium.org> wrote: > > > On Fri, Apr 26, 2024 at 4:09 AM Domenic Denicola <dome...@chromium.org> > wrote: > >> >> >> 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? >> > > Yes, consider it withdrawn. I am happy with this outcome for now. > > >> >>> 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. >> > > 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 >> <https://www.chromium.org/blink/guidelines/web-platform-changes-guidelines/> >> 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 > > <https://github.com/w3c/csswg-drafts/issues/10234#issuecomment-2067727812:~:text=after%20even%20longer.-,To%20be%20clear%2C%20this%20issue%20blocks%20actually%20carrying%20out,-%238738.%20The%20more> > that Issue 10234 would block carrying out @nest in practice. > - But then prominent CSSWG members clarified that, no, it should > <https://github.com/w3c/csswg-drafts/issues/10234#issuecomment-2067746133> > not > <https://github.com/w3c/csswg-drafts/issues/10234#issuecomment-2069212736> > 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 > <https://github.com/w3c/csswg-drafts/issues/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. > > >> >>> >>> 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/CAKFBnUou98dbsCej%3Dji3AgL7-esjCzvnYUByA6hG6PKzZ2vdQw%40mail.gmail.com.
