[csswg-drafts] [css-nesting] Require `div&`, disallow `&div`, for Sass compat (#8662)

tabatkins has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-nesting] Require `div&`, disallow `&div`, for Sass compat ==
Given [the very heartening news that infinite-lookahead is viable in Chrome](https://github.com/w3c/csswg-drafts/issues/7961#issuecomment-1489883575), I'd like to try and revisit one of our syntax changes caused by Nesting.

In the original version of the spec, you had to start a selector with `&`, so to handle the case where you want to add a type selector, we relaxed the restriction that a type selector had to be the first thing in a compound selector. This allowed `&div` to work, tho `div&` was theoretically okay (in cases like `@nest div&`).

In the current version of the spec, you still can't start a selector with an ident, so `&div` is still the right way to spell things most of the time (but again, still okay in theory to do the other way, like `.foo div&`).

Neither of these restrictions will apply anymore if #7961 goes thru. Which is good, *because `&div` is terrible for Sass*.

Sass essentially uses text concatenation for its nesting feature. If you write `.foo { &div {...}}` in Sass, it generates a `.foodiv {...}` rule - a single larger class selector. In CSS Nesting, this is instead equivalent to `div.foo {...}` - a type selector plus a class selector.

This mismatch in syntax was *always* going to be an enormous pain for Sass to migrate to CSS Nesting (possibly a straight-up blocker, requiring Sass users to explicitly opt into CSS Nesting instead), but when other factors made `&div` the preferred form, I accepted that it was just one of those painful situations that'll be worth it in the long term.

But given #7961, there's no longer any reason to prefer `&div` over `div&`. So we can simultaneously (a) remove a syntax change, preserving the original syntax of Selectors that has been stable for a long time, and (b) make Sass's task of migrating to CSS Nesting natively *massively* easier (along with any other preprocessor that has a similar feature, but I'm familiar with Sass's syntax here).

I've talked with @andruud about this and he's dropping a Use Counter into Chrome preemptively, to make sure we'll actually be able to make this change. (Since we're planning to ship the current Nesting spec in Chrome 112, but infinite-lookahead will be a future version.)

/cc @nex3 

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8662 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 30 March 2023 15:45:30 UTC