Re: [csswg-drafts] [css-nesting-1] Syntax Invites Errors (#7834)

It seems that all of the pushback centers around requiring the first selector to start with `&` (unless preceded by an @-rule) while subsequent ones don't.
[We are converging towards a variation of the proposal](https://github.com/w3c/csswg-drafts/issues/7834#issuecomment-1270665794) where the *only* cases that actually require the `&` are selectors that start with a tag name.

Here's a crazy idea: What if we just *don't* allow nested selectors to start with a tag name at all, anywhere? Then there is no different handling of the first rule which some people seem to react strongly against, and *any* nested rule kicks the parser into rule mode, and authors can always use `:is(tag)` for the cases where they need this. 

There is somewhat similar precedent in CSS: regular selectors cannot have tags anywhere in the middle, they can only start with a tag, unless `:is()`/`:where()` is used. Not the same thing, but there is precedent for having special parsing rules around tag selectors.

Also, if at some point in the future CSS grammars have to become LR(2) for other reasons, we can allow nested selectors to start with a tag then.

Note that this will be valid with this proposal:

```css
.foo {
 .bar strong {
 }

 & strong {

 }
}
``` 

> And regarding to defaulting to descentant combinator, it's not clear to me at all why

Not just preprocessors, but also our own `:has()`, and `@scope`. 

-- 
GitHub Notification of comment by LeaVerou
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7834#issuecomment-1272373216 using your GitHub account


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

Received on Saturday, 8 October 2022 18:22:20 UTC