Intent to Ship: CSS Nesting

[Steinar H. Gunderson]

Contact emails: se...@chromium.org, fut...@chromium.org
Explainer: None

Specification: https://drafts.csswg.org/css-nesting

Summary: Add the ability to nest CSS style rules inside other style rules,
combining selectors from the outer with the inner rule for increasing
modularity and maintainability of style sheets.

Blink component: Blink>CSS

TAG review: https://github.com/w3ctag/design-reviews/issues/791

TAG review status: Pending

Risks: There is a threat of a formal objection in CSSWG.

Interoperability and Compatibility:

Gecko: Positive (https://github.com/mozilla/standards-positions/issues/695)
WebKit: Positive (https://github.com/WebKit/standards-positions/issues/69)

Debuggability
Nesting style rules will be a big change for editing and displaying style rules in the inspector:

- Showing displaying nested rules for matching declarations
- Editing selectors
- Inserting nested rules
- etc...

Tracking issue for devtools support: https://crbug.com/1172985
Devtools says they're on track for shipping in M111.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux,
Chrome OS, Android, and Android WebView)? Yes

Is this feature fully tested by web-platform-tests? Yes

Flag name: CSSNesting

Requires code in //chrome? False

Tracking bug: https://crbug.com/1095675

Estimated milestones
DevTrial on desktop 109
DevTrial on Android 109
Shipping 112


Anticipated spec changes: See above.

Link to entry on the Chrome Platform Status:
https://chromestatus.com/feature/5800613594529792

Links to previous Intent discussions:
Intent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/YzrEmc%2BqlqPv72Au%40google.com

--
Software Engineer, Google Norway

[Mike Taylor]

Hi Steiner,

I spent quite a lot of time trying to understand the issues around
nesting syntax. It looks like the CSSWG resolved to adopt "Option 3",
with representatives from all 3 engines voting in favor - and the WebKit
blog survey also resulted in "Option 3" as the top choice.

Do we know if the other engines have started work on implementation of
Option 3?

thanks,
Mike

[Yoav Weiss]

On Mon, Jan 23, 2023 at 5:37 PM Mike Taylor <mike...@chromium.org> wrote:

Hi Steiner,

I spent quite a lot of time trying to understand the issues around
nesting syntax. It looks like the CSSWG resolved to adopt "Option 3",
with representatives from all 3 engines voting in favor - and the WebKit
blog survey also resulted in "Option 3" as the top choice.

Do we know if the other engines have started work on implementation of
Option 3?

thanks,
Mike

On 1/20/23 4:42 AM, 'Steinar H. Gunderson' via blink-dev wrote:
> Contact emails: se...@chromium.org, fut...@chromium.org
> Explainer: None
>
> Specification: https://drafts.csswg.org/css-nesting
>
> Summary: Add the ability to nest CSS style rules inside other style rules,
> combining selectors from the outer with the inner rule for increasing
> modularity and maintainability of style sheets.
>
> Blink component: Blink>CSS
>
> TAG review: https://github.com/w3ctag/design-reviews/issues/791
>
> TAG review status: Pending
>
> Risks: There is a threat of a formal objection in CSSWG.

Can you expand on that?

 

--
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/be91b584-f0ba-cd60-a142-f60c3aa72709%40chromium.org.

[Philip Jägenstedt]

I think that we should ship this. It's a high profile and in-demand new feature, so I have a few questions and comments first.

Taking a look at the open spec issues (https://github.com/w3c/csswg-drafts/labels/css-nesting-1) some are explicitly ideas for future changes, but are there any where shipping amounts to a decision that isn't easily changed? I'm thinking especially of the CSSOM issues.

In https://wpt.fyi/results/css/css-nesting there's a single subtest failure, related to how a rule serializes. Is that implemented per spec, or is it tied up with the open CSSOM issues?

Regarding the threat of a formal objection, there doesn't appear to be any solution that would fully satisfy everyone, but I trust your judgment that this is the best option. Additionally, we should not pre-commit Blink to shipping parser changes, and accept the possibility that what we ship now is the final shape of the feature.

--
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/Y8ph9gk50U2D92f3%40google.com.

[Steinar H. Gunderson]

On Mon, Jan 23, 2023 at 11:37:21AM -0500, Mike Taylor wrote:
> I spent quite a lot of time trying to understand the issues around nesting
> syntax. It looks like the CSSWG resolved to adopt "Option 3", with
> representatives from all 3 engines voting in favor - and the WebKit blog
> survey also resulted in "Option 3" as the top choice.
>
> Do we know if the other engines have started work on implementation of
> Option 3?

As far as I know, WebKit is indeed working an implementation of Option 3.

/* Steinar */

[Rune Lillesveen]

Enabled feature for preview (TP?) here:

https://github.com/WebKit/WebKit/commit/ceafa556d06a475ae4b9362abeb64a42128ce9ee

--

Rune Lillesveen

[Manuel Rego Casasnovas]

Adding to Philip questions, there seems to be quite a lot of ongoing
discussions around this topic on the CSSWG, for example today there's a
special meeting only for CSS Nesting topics:
https://lists.w3.org/Archives/Public/www-style/2023Jan/0011.html

What's their impact on the current implementation?

Thanks,
Rego

On 23/01/2023 18:00, Philip Jägenstedt wrote:
> I think that we should ship this. It's a high profile and in-demand new
> feature

> <https://2022.stateofcss.com/en-US/usage/#missing_features_freeform>, so

> I have a few questions and comments first.
>
> Taking a look at the open spec issues
> (https://github.com/w3c/csswg-drafts/labels/css-nesting-1

> <https://github.com/w3c/csswg-drafts/labels/css-nesting-1>) some are

> explicitly ideas for future changes, but are there any where shipping
> amounts to a decision that isn't easily changed? I'm thinking especially
> of the CSSOM issues.
>
> In https://wpt.fyi/results/css/css-nesting
> <https://wpt.fyi/results/css/css-nesting> there's a single subtest
> failure, related to how a rule serializes. Is that implemented per spec,
> or is it tied up with the open CSSOM issues?
>
> Regarding the threat of a formal objection, there doesn't appear to be
> any solution that would fully satisfy everyone, but I trust your
> judgment that this is the best option. Additionally, we should not
> pre-commit Blink to shipping parser changes, and accept the possibility
> that what we ship now is the final shape of the feature.
>
> On Fri, Jan 20, 2023 at 10:42 AM 'Steinar H. Gunderson' via blink-dev

> <blin...@chromium.org <mailto:blin...@chromium.org>> wrote:
>
> Contact emails: se...@chromium.org <mailto:se...@chromium.org>,
> fut...@chromium.org <mailto:fut...@chromium.org>

> Explainer: None
>
> Specification: https://drafts.csswg.org/css-nesting
> <https://drafts.csswg.org/css-nesting>
>
> Summary: Add the ability to nest CSS style rules inside other style
> rules,
> combining selectors from the outer with the inner rule for increasing
> modularity and maintainability of style sheets.
>
> Blink component: Blink>CSS
>
> TAG review: https://github.com/w3ctag/design-reviews/issues/791
> <https://github.com/w3ctag/design-reviews/issues/791>
>
> TAG review status: Pending
>
> Risks: There is a threat of a formal objection in CSSWG.
>
> Interoperability and Compatibility:
>
> Gecko: Positive
> (https://github.com/mozilla/standards-positions/issues/695

> <https://github.com/mozilla/standards-positions/issues/695>)
> WebKit: Positive
> (https://github.com/WebKit/standards-positions/issues/69
> <https://github.com/WebKit/standards-positions/issues/69>)

>
> Debuggability
> Nesting style rules will be a big change for editing and displaying
> style rules in the inspector:
>
> - Showing displaying nested rules for matching declarations
> - Editing selectors
> - Inserting nested rules
> - etc...
>
> Tracking issue for devtools support: https://crbug.com/1172985
> <https://crbug.com/1172985>
> Devtools says they're on track for shipping in M111.
>
> Will this feature be supported on all six Blink platforms (Windows,
> Mac, Linux,
> Chrome OS, Android, and Android WebView)? Yes
>
> Is this feature fully tested by web-platform-tests? Yes
>
> Flag name: CSSNesting
>
> Requires code in //chrome? False
>

> Tracking bug: https://crbug.com/1095675 <https://crbug.com/1095675>

>
> Estimated milestones
> DevTrial on desktop     109
> DevTrial on Android     109
> Shipping                112
>
>
> Anticipated spec changes: See above.
>
> Link to entry on the Chrome Platform Status:
> https://chromestatus.com/feature/5800613594529792
> <https://chromestatus.com/feature/5800613594529792>
>
> Links to previous Intent discussions:
> Intent to prototype:

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/YzrEmc%2BqlqPv72Au%40google.com <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/YzrEmc%2BqlqPv72Au%40google.com>

>
> --
> Software Engineer, Google Norway
>
> --
> 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

> <mailto:blink-dev%2Bunsu...@chromium.org>.

> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/Y8ph9gk50U2D92f3%40google.com <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/Y8ph9gk50U2D92f3%40google.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+...@chromium.org

> <mailto:blink-dev+...@chromium.org>.

> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYdMTE%3DjWA4AVXeJfGGTZ5WNzQCR4MiHONuZD3gq43PAOg%40mail.gmail.com <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYdMTE%3DjWA4AVXeJfGGTZ5WNzQCR4MiHONuZD3gq43PAOg%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Philip Jägenstedt]

LGTM1

I had a chat with Steinar today to answer my questions. Out of the open issues, the important ones to resolve before shipping are:

https://github.com/w3c/csswg-drafts/issues/7850

https://github.com/w3c/csswg-drafts/issues/7971

https://github.com/w3c/csswg-drafts/issues/7972

Those don't seem controversial. My LGTM is assuming spec and tests are updated and that we pass those tests before the feature reaches stable.

The final test failure is related to #7850 and is an easy fix.

Regarding the syntax, there's still disagreement in the CSSWG. Unanimous consensus among all WG members doesn't seem possible here, for any proposal. Crucially, other browser vendors appear to be OK with "option 3". I would definitely reconsider my LGTM if there were signs that other browser vendors are not keen on shipping option 3, since that would create an interop problem, and eventually site compat problems as well.

As always, we should be receptive to new information even after an intent has been approved and the flag has been flipped.

[Rick Byers]

We discussed this in the API owner meeting today (Philip, Rego, Daniel, Chris, Yoav, Mike Taylor and myself). We appreciate that there's not yet full consensus on the API syntax, but also that we've been in this state for several months and we've heard pretty clearly from web developers that as a whole they want us to ship something and overwhelmingly support option 3. It seems to me we're in real danger of a priority of constituencies inversion here with authors continuing to lose out as a result of indecision from the implementer and standards community. 

Therefore, since option 3 seems to have the bulk of support from web developers and browser implementers, I agree with Philip that, absent any stronger consensus emerging, we should proceed with shipping it for M112 (not M111 which is branching this week). LGTM2 (with the same criteria as Philip). 

However, if the CSSWG resolves to materially change the design or the TAG completes their review and requests specific breaking changes prior to Chrome 112 going to Beta around March 1st, then I'd retract my LGTM and ask us to flag it back off and circle back here to allow for a new attempt at building more consensus. As always, some breaking changes may be possible after that point too, but it'll depend on the realities of web compat.

API owners also agreed that we'd look for 4 LGTMs in this case instead of the usual 3. 

Thanks,

  Rick

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/CAARdPYckGUc%3DxjifpXRrOi_UQ2SCXO%2B68GuDAT4r0B%2B8qC4WSw%40mail.gmail.com.

[Mike Taylor]

LGTM3 with same conditions outlined by Rick and Philip.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY8gz3jMDHJHDiNtuhA3S2bQ7j30WJirJ%3DWCevpxCpEivw%40mail.gmail.com.

[Yoav Weiss]

LGTM4, with the same criteria!

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/579baa85-3561-9614-102b-a20ae14a9fdf%40chromium.org.

[obr...@igalia.com]

I don't see the danger of a priority of constituencies inversion. Authors can use preprocessors, just like they have been using for several years, so I don't get where the hurry comes from.

In fact, I would argue that hurrying to ship a future without having discussed the details just tends to result in a messier language that ends up causing more author frustration in the long-term.

And it's not just about the bigger controversy of choosing "option 3" vs something else, with the risk of a formal objection. There are various other relevant details.

For example, just yesterday the CSSWG resolved that `:is(.baz, !&)` should count as containing `&`, and thus match any `.baz` in the page, not just `& .baz` like the current implementation.
It was also resolved that raw properties in a nested media rule are wrapped in a `& {}` rule, which matches Blink, but there are still some details to discuss, which may or may not match the implementation.

And there are more issues in the agenda.

Some of these topics may be minor, or might be fixed before 112 goes into beta. But I don't see why risk shipping something in a hurry without proper discussion, potentially leading to compat problems when trying to change the behavior later.

-- Oriol Brufau

El dia dimecres, 25 de gener de 2023 a les 18:31:03 UTC+1, rby...@chromium.org va escriure:

[Philip Jägenstedt]

Hi Oriol,

Thanks for raising that there may be some spec changes that don't match the current implementation. Can you list which issues you think need to be resolved? There are already 3 listed upthread, and I agree that anything that has a non-trivial risk of causing interop/compat problems down the line is worth spending extra time on.

Best regards,

Philip

[Rick Byers]

Yes thanks for weighing in Oriol, I appreciate it - especially in cases like this when reasonable and well-meaning people may disagree strongly on the best course of action. I agree that we should do our reasonable best to identify and resolve such outstanding issues to minimize the risk of having a future compat problem.

I do want to candidly address your "why the hurry" question though. I personally see having some urgency to ship as being an important balance against the tendency to get stuck debating some design detail well past the point of being a reasonable ROI. All engineering is a cost/benefit tradeoff and I always advise web teams that we should be happy to invest 10x the cost of "going it alone" in order to get consensus, but not 100x the cost. There's a fixed level of investment available for making the web better, and when we fall into the trap of spending 100x in trying to get broader consensus, it means we're depriving 9 other features in the 10x bucket from existing.

So for nesting, I'm personally reacting to what feels to me like an overly long debate around the core syntax of this feature. We surveyed developers about this question a full 6 months ago, and we're apparently still spending huge amounts of energy debating this syntax choice. As an API OWNER, I have a responsibility to the chromium community to empower them to proceed with improving chromium without being blocked indefinitely. In this case I was unable to come up with anything reasonable I could ask an engineer to do to realistically unblock the core debate, so rather than tell them they need to keep waiting and hoping for total consensus I feel I must say "please ship the best design you've got given the large investment made in consensus so far". Alternately, if there's really no harm for the web to have developers just continuing to use preprocessors, then we could instead cancel the feature as being too high a cost given the apparently low benefit and save us all the hassle.

But this is a tricky tradeoff, I'm seeing only a tiny bit on the surface myself and not deep into it like yourself (both an advantage and disadvantage). I'm open to being wrong and appreciate being able to have a candid and respectful public conversation about the tradeoffs. If you and other folks active in the CSSWG discussions feel that another month of hard work would lead to a much more stable and agreed upon design, then I'm willing to support slipping another milestone. So I think that leaves me with the same basic question as Philp - what is the concrete and pragmatic list of work necessary to get this feature to a reasonable and pragmatic state for shipping a v1.0 soon, on top of which we can continue iterating together?

Thanks,

   Rick

[Alex Russell]

+1 to Rick's notes about "why the hurry"; there is a high cost to not doing the good we can do in a timely way, and shipping important features is how we make the world better -- and also worse, which is why we hold the train in many cases, but only for a limited time. Transpilers are a tax, not a solution, and if our mental model of platform development admits a view that we should tax developers with transpilers constantly, we've failed.

For context, we first proposed a compatible nesting syntax in 2011:

    https://www.youtube.com/watch?v=qzA60hHca9s

Like variables and many other long-delayed CSS features, this is so far overdue that doing something is strongly preferable to being wrong.

So, on balance, this is an easy one. It doesn't need another vote, but in the interest of overwhelming support, LGTM5.

Best,

Alex

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_GfAW6OMy%3DV1ziiqSR2Qrs405KN8nd%2BBzF%3DHb8pqisFg%40mail.gmail.com.

[obr...@igalia.com]

Sorry for the delay, I will try to answer the various points raised:

> Thanks for raising that there may be some spec changes that don't match the current implementation. Can you list which issues you think need to be resolved? There are already 3 listed upthread, and I agree that anything that has a non-trivial risk of causing interop/compat problems down the line is worth spending extra time on.

My concern is not just about a specific list of important issues, it's also that new issues keep appearing.
For example, 3 weeks ago, tab proposed a change that would have required heavy changes in the implementation: https://github.com/w3c/csswg-drafts/issues/8310
That one was retracted, but e.g. just last week Domenic proposed changing the CSSOM API: https://github.com/w3c/csswg-drafts/issues/8350
I expect more of these proposals to keep appearing as the spec stabilizes and people get a better idea of the feature.
Probably not that many will be accepted, but if you ship first, then compat may prevent adopting some of these changes.
There are also gotchas like https://github.com/w3c/csswg-drafts/issues/8349, even if they don't result in any change, it's beneficial for authors if these potential problems are detected and documented before they start using the feature.

> I'm personally reacting to what feels to me like an overly long debate around the core syntax of this feature. We surveyed developers about this question a full 6 months ago, and we're apparently still spending huge amounts of energy debating this syntax choice.

I can understand this position about the core syntax, which has been more controversial with long discussions.
But there are things like https://github.com/w3c/csswg-drafts/issues/7850, which need to be resolved but probably won't be that controversial and won't take long.

> If you and other folks active in the CSSWG discussions feel that another month of hard work would lead to a much more stable and agreed upon design, then I'm willing to support slipping another milestone.

I think one month could help figuring out some of these less controversial details.
And also, about the core syntax syntax controversy, Emilio volunteered to investigate the feasibility of unbounded lookaheads in a CSS parser "in the next month" (this was said 2 weeks ago).
If such lookaheads are possible, they may reduce the constraints that nesting imposes on the language, and avoid closing the door to some potential future extensions in the syntax of selectors or declarations. Then Peter won't do the formal objection.

> what is the concrete and pragmatic list of work necessary to get this feature to a reasonable and pragmatic state for shipping a v1.0 soon, on top of which we can continue iterating together?

As said earlier, some backwards incompatible proposals have appeared recently, and more may appear soon. So this is not concrete, but I think that giving some time for this is good.
Then https://github.com/w3c/csswg-drafts/labels/css-nesting-1 has some issues that the CSSWG hasn't discussed at all yet, or some which have been resolved but not implemented.
For example, https://github.com/w3c/csswg-drafts/issues/5745 resolved to accept the selector & everywhere, defaulting it to :scope. But from a quick test it seems that querySelector and querySelectorAll just return null or empty array. I guess that implementing this properly may wait, but then meanwhile it would probably be better to make these methods throw as they do for invalid selectors. Otherwise it will be annoying for authors if they want to know if there is no match indeed, or the implementation doesn't support that yet.
I'm also concerned that the TAG still hasn't had time to review the feature. Waiting one month can give them some time I guess, but I don't know their timing constraints.

> Transpilers are a tax, not a solution

I agree, but given that people have been using transpilers for this for a long time, and the feature is basically a syntax sugar convenience so it's not giving more power to authors, it seems better to wait a bit more. It can actually be less convenient for authors if the feature ships earlier but then it has to change soon afterwards.

El dia dilluns, 30 de gener de 2023 a les 19:53:15 UTC+1, sligh...@chromium.org va escriure:

[Steinar H. Gunderson]

On Wed, Feb 01, 2023 at 12:27:08AM -0800, obr...@igalia.com wrote:
> For example, https://github.com/w3c/csswg-drafts/issues/5745 resolved to
> accept the selector & everywhere, defaulting it to :scope. But from a quick
> test it seems that querySelector and querySelectorAll just return null or
> empty array. I guess that implementing this properly may wait, but then
> meanwhile it would probably be better to make these methods throw as they
> do for invalid selectors.

FWIW, this change was sent for review as soon as I actually foud out
that the spec had changed (which was yesterday afternoon, so the patch
hasn't been reviewed yet). We couldn't throw, because & on top-level was
allowed before, just defined never to match.

/* Steinar */

[Sebastian Zartner]

I believe, one major issue for the adoption of nesting and which should block shipping it is feature detection. There needs to be a clear way for authors to detect whether the browser supports nesting rules, i.e. provide them with a way to transition to nesting. Without feature detection, authors will write pages that break in browsers that don't support it or they will simply not use the feature.

I've therefore created an issue to discuss this.

Sebastian

[Philip Jägenstedt]

Feature detection will be possible using `@supports selector(&)`. Due to a bug there was a false positive with the flag turned off, but that's been fixed in https://bugs.chromium.org/p/chromium/issues/detail?id=1414012 today and a backport to 111 has been requested.

The false positive will remain in Chrome 109 and 110. That's unfortunate, but I don't see a clear way to get around the problem.

[obr...@igalia.com]

This is another reason to delay the shipment: reducing the number of users in 109 and 110 will make the check somewhat more reliable.

El dia dimecres, 8 de febrer de 2023 a les 17:32:50 UTC+1, Philip Jägenstedt va escriure:

[Bramus Van Damme]

On Thursday, February 9, 2023 at 3:20:34 PM UTC+1 obr...@igalia.com wrote:

This is another reason to delay the shipment: reducing the number of users in 109 and 110 will make the check somewhat more reliable.

If they want, authors can work around this mistake by also testing for a feature that ships in any release after M110. A good candidate would be cos(), which ships in M111: `@supports selector(&) and (scale: cos(90deg)) { … }`. That way M109 and M110 are excluded. Admittedly, this is a very nasty workaround.

OTOH: Will authors actually need to feature detect this? I mean, feature detection won’t make a difference to visitors as it will have the same net outcome to them: the nested styles will not be applied in browsers that don’t support nesting. Only difference is that the parser might need to parse a bunch of extra things instead of being able to discard entire blocks upfront.

[Bramus Van Damme]

(Hmm, looks like something went wrong with posting my previous message through the web UI. For clarity, I’m re-sending the relevant part.)

If they want, authors can work around this mistake by also testing for a feature that ships in any release after M110. A good candidate would be cos(), which ships in M111: `@supports selector(&) and (scale: cos(90deg)) { … }`. That way M109 and M110 are excluded. Admittedly, this is a very nasty workaround.

OTOH: Will authors actually need to feature detect this? I mean, feature detection won’t make a difference to visitors as it will have the same net outcome to them: the nested styles will not be applied in browsers that don’t support nesting. Only difference is that the parser might need to parse a bunch of extra things instead of being able to discard entire blocks upfront.

B!

You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/eFCrkiLynfU/unsubscribe.
To unsubscribe from this group and all its topics, 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/32a43824-1b71-4b67-b1ce-05c4e9b1fc7dn%40chromium.org.

[Sebastian Zartner]

On Thu, 9 Feb 2023 at 23:59, Bramus Van Damme <bra...@chromium.org> wrote:

OTOH: Will authors actually need to feature detect this? I mean, feature detection won’t make a difference to visitors as it will have the same net outcome to them: the nested styles will not be applied in browsers that don’t support nesting. Only difference is that the parser might need to parse a bunch of extra things instead of being able to discard entire blocks upfront.

Without feature detection, authors are left with three choices:

1. Always include both nested and unnested rules ⇒ more network traffic
2. Only include nested rules ⇒ layout is broken for browsers not supporting nested rules
3. Avoid nesting rules ⇒ CSS Nesting failed
   

None of those choices is great and I am relatively confident that the majority of authors will choose option 3 to avoid page breakage or unnecessarily bloating their pages.

We already have a similar issue with the adoption of @layer which is currently also not feature detectable (because browsers don't support @supports at-rule() yet).

Sebastian

[Jen Simmons]

> If they want, authors can work around this mistake by also testing for a feature that ships in any release after M110. A good candidate would be cos(), which ships in M111: `@supports selector(&) and (scale: cos(90deg)) { … }`. That way M109 and M110 are excluded.

This only works if web developers are making websites that are intended to only work in Chrome. 

[Bramus Van Damme]

> > If they want, authors can work around this mistake by also testing for a feature that ships in any release after M110. A good candidate would be cos(), which ships in M111: `@supports selector(&) and (scale: cos(90deg)) { … }`. That way M109 and M110 are excluded.

> This only works if web developers are making websites that are intended to only work in Chrome. 

Safari 15.4 and Firefox 108 support the cos() trig function.

[obr...@igalia.com]

Will authors actually need to feature detect this? I mean, feature detection won’t make a difference to visitors as it will have the same net outcome to them: the nested styles will not be applied in browsers that don’t support nesting.

I can imagine authors using nesting in inline styles, and then using a JS polyfill to manually parse and desugar them. But of course no need to do that work if nesting is supported, and checking if & is a valid selector seems the obvious way.

Authors may then write a function that is supposed to return whether nesting is supported, and even test that it effectively returns false on Firefox, and true on Chrome (after nesting is released).

But they may not check old versions of Chrome (it's hard since it updates automatically), and thus fail to notice the false positive that prevents the polyfill from running.

This is not some unlikely hypothetical scenario, the code that I posted in https://github.com/w3c/csswg-drafts/issues/8399#issuecomment-1416869274 would have suffered from this.

[Anders Hartvoll Ruud]

PSA: CSS Nesting Still Shipping in M112

I've been experimenting with parser restarts in Blink lately, which would allow nested selectors that start with tag names. I've shared my results with the CSSWG (Issue 7961, comment).

We still don't know the outcome of that issue, so shipping CSS Nesting per the current spec revision will proceed as planned. If Issue 7961 does lead to a change, it will be backwards compatible with what we're about to ship.