CSS Nesting: @nest

[andruud]

WebKittens

@mdubet

Title of the spec

CSS Nesting

URL to the spec

https://drafts.csswg.org/css-nesting-1/#nest-rule

URL to the spec's repository

No response

Issue Tracker URL

No response

Explainer URL

No response

TAG Design Review URL

No response

Mozilla standards-positions issue URL

https://github.com/mozilla/standards-positions/issues/1013

WebKit Bugzilla URL

No response

Radar URL

No response

Description

Basically this proposal from Tab.

I am a bit reluctant to ship this since we have a major open issue about how it should appear in CSSOM (https://github.com/w3c/csswg-drafts/issues/10234), but apparently the CSSWG wants to ship @nest as currently specified now, then consider any additional changes later (https://github.com/w3c/csswg-drafts/issues/10234#issuecomment-2067746133, https://github.com/w3c/csswg-drafts/issues/10234#issuecomment-2069212736).

So I am specifically asking for a position on shipping the (possibly intermediate) state of @nest as it's currently specified, despite https://github.com/w3c/csswg-drafts/issues/10234 not being resolved.

[LeaVerou]

Thanks for filing this @andruud! To add context, @nest will resolve this major current issue with CSS Nesting: https://github.com/w3c/csswg-drafts/issues/8738 by providing implementations a way to represent interleaved declarations and rules in the OM.

The major open issue is about the specifics of this new rule (does it serialize as a rule? Can authors write @nest {...} or is it an internal CSS OM detail?) but we have consensus that:

1. It is much easier to change the specifics of this rule than fix the CSS Nesting issue later as the current behavior becomes more entrenched.
2. Even the wrong @nest behavior (whatever that is) is better than hoisting interleaved declarations up in CSS Nesting, which is not only unexpected, but creates roadblocks for future tech like mixins.

Given 1, and considering that WebKit was among the folks pushing for a non-author facing @nest, 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.

[andruud]

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

To clarify: I'm specifically asking for a position on @nest as it's currently specified, in its full author exposed glory, to avoid a potentially massive interop regression. If WebKit intends to ship anything else, then I expect the position to clearly reflect that.

[tabatkins]

simply implement a non author-facing @nest

There is no such thing as a "simple non-author-facing @nest", which is the point of a lot of the discussion in the WG. Every possibility for doing so introduces additional complexities.

[fantasai]

WebKit strongly opposes introducing an @nest rule for this purpose. We don't think expanding the syntax space of CSS for the convenience of CSSOM representation is an acceptable cost to authors, and prefer a solution that represents interleaved style declarations in the CSSOM in a way that does not have an externality on CSS syntax.

[annevk]

I'm removing "position: oppose" for now to allow for a week of feedback, but barring any other feedback that will be WebKit's position.

[emilio]

We don't think expanding the syntax space of CSS for the convenience of CSSOM representation is an acceptable cost to authors, and prefer a solution that represents interleaved style declarations in the CSSOM in a way that does not have an externality on CSS syntax.

Well, such thing would involve substantial cost to both authors and CSSOM IMO.

In particular, we'd need to either:

• Make .cssRules not return rules (and return rules-or-something-else), insertRule parse bare declarations and not just rules, and a long etc I've probably haven't thought through, or...

• Create a whole lot of new API surface to represent this, that duplicates all the existing API surface, which now would no longer work and would need to be deprecated. Also, define how the existing API surface behaves in presence of mixed declarations, e.g., what are indices relative to, where do you insert if you choose an index between rules where there are bare declarations in-between too (because it does matter whether you insert it before or after the declarations)...

Both of those approaches seem terrible to me. But maybe there's something I'm missing about what the WebKit preference would be?