So we are back to the worst possible outcome? :( ☆*PhistucK*
On Sat, Apr 27, 2024 at 8:31 AM Anders Hartvoll Ruud <andr...@chromium.org> wrote: > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKFBnUou98dbsCej%3Dji3AgL7-esjCzvnYUByA6hG6PKzZ2vdQw%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/CABc02_KQfTWWqtRMk6X%3DZf%2BDtjWVsXLC42cOmaqt4MhQ6G5eGA%40mail.gmail.com.
