On 4/25/24 7:09 PM, Domenic Denicola 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
<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-colorof <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 howto
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 <http://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 apparentpositions 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?
+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
<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.
Strong agree here.
--
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/07f0f8f2-1f60-4c37-8771-599cc4204050%40chromium.org.
