[csswg-drafts] [css-nesting] Problem with mixing properties and selectors (#8249)

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

== [css-nesting] Problem with mixing properties and selectors ==
As [mentioned](https://github.com/w3c/csswg-drafts/issues/8248#issuecomment-1361769179) I'm opening a new issue to outline the objections I raised in the call today and to discuss paths forward.

My primary objection to the current syntax is that mixing properties and selectors without a clear distinction places unacceptable (to me) restrictions on the future design of the CSS language. 

An implementation parsing a style declaration will need to presume anything that doesn't start with an identifier or function is a selector, which restricts our ability to ever extend property declarations with anything that doesn't start with an identifier or function. Furthermore this restricts our ability to ever extend the definition of an identifier or a function. As an example, if this were implemented first, we could never have added custom properties with the current syntax (which redefined identifiers).

Alternatively, we could limit selector combinators to the current set and a limit extension path, like `/<name>/`, this would place restrictions on future selector syntax and potentially add more confusion as to the rule of when a `&` or the `:is()` hack is required. Not a fan of this.

I see two paths forward (and welcome other suggestions):

1) We remove the lookahead restrictions on the parser and 'simply' adopt the SASS syntax. The lookahead restriction came about 25 years ago when there were real concerns that CSS would be too slow to ever implement in a browser and everything was focused on performance. I'd like to see some experimentation and real-world data to check that assumption and see if advancements in processor speed and RAM availability allow us to relax that.

2) We add something that clearly distinguishes selectors from properties within a style declaration. 

Something like:
```css
div {
  color: red;
  @nest span {
    color: blue;
  }
```
is fine by me, but I accept that this has been proposed in the past and rejected.

A compromise I'd be OK with would be treating a bare `@` inside a declaration as the equivalent to `@nest` (and possibly allowing `@nest` to be optional for those wanting clarity). This is functionally equivalent to requiring the `&` (which many people in the polls preferred), but also handles cases where the `&` isn't the start of the selector without adding lookahead. e.g.:
```css
div {
  color: red;
  @ span {
    color: blue;
  }
  @ &:hover {
    color: green;
  }
  @ section & {
    color: yellow;
  }
}
```

This leverages the fact that `@` is already CSS's universal escape hatch and clearly distinguishes properties and selectors, allowing unrestricted extensions of either in the future. It also minimizes verbosity as the majority of nested selectors can simply start with an `@` and requires no other changes or special rules to learn.  



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


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

Received on Wednesday, 21 December 2022 18:56:24 UTC