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

> The whole point of the nesting feature is to be easier to type and maintain than repetition, so adding an extra indentation level and a sizeable prefix will get a strong opposition from authors, because it's defeating the point of the feature

The repetition we save is in the selector list, which can be huge, that doesn't change with an at-rule or any other required prefix. Adding an `&` wasn't seen as an unacceptable burden, I don't see why 4 extra characters would make it so. Extra indentation isn't necessary (may be desired in some cases) but hardly defeats the point of nesting. That's a bit hyperbolic. Also, `@nest` isn't all that large as far as at-rule names go, we could even make it shorter if 5 characters is an untenable burden at the cost of readability. (I wish we could use a bare `@` but older browsers don't treat that as an at-rule.)

There are also multiple forms an at-rule approach can take, and as I said, we can support several or all of them simultaneously.

For example:
1) `@nest [selector-list] { [declaration-block] }`, allowed inside declaration blocks. No extra indenting.
```css
div {
  background: blue;
  @nest span {
    background: green;
  }
  @nest b {
    background: yellow;
  }
}
```
2) `@nest [selector-list] { [list-of-nested-rules-only] }`, allowed at top level only. Adds potential indenting for primary rule declarations.
```css
@nest div {
  {
    background: blue;
  }
  span {
    background: green;
  }
  b {
    background: yellow;
  }
}
```
3) `@nest { [list-of-nested-rules-only] }`, allowed inside declaration blocks only. Adds potential indenting for nested rules.
```css
div {
  background: blue;
  @nest {
    span {
      background: green;
    }
    b {
      background: yellow;
    }
  }
}
```

All of the above provide author flexibility and avoid the mixed rules and declarations problem.

> I would argue that the parser changes proposed here are marginal, and will not affect current authors at all.

The overall concern about parser changes isn't about impact to authors, it's about impact to the language. The real risk is always things we're not foreseeing now that will come around and bite us later when we try to add something new.

> Do you have an example?

See [above](https://github.com/w3c/csswg-drafts/issues/8249#issuecomment-1498379095) and several other conversations about how declaration error recovery and rule error recovery differ. By putting rules in a place where declarations are expected, we run the risk of using the wrong recovery mode, which can eat valid following declarations and lead to site breakage in ways that will surprise authors.

The primary benefit of an at-rule approach is that all browsers that ever supported CSS drop into rule recovery mode when they see an at-rule in a declaration block, so there are no side-effects or surprises to authors. It's been the extension mechanism from day 1, and we're proposing to not use it.

> I agree, but this is orthogonal. There is currently no way to detect the support of an at-rule either.

It's orthogonal, but shipping nesting without feature detection makes the nesting feature useless for anyone who cares about supporting older browsers, especially during the transition phase as the feature rolls out and isn't universally available (we really don't want to encourage 'best viewed in X' again, do we?). Authors will either ship only nested stylesheets and break their sites for older browsers; ship both, making the user pay unnecessary download costs (violating one of the TAG's ethical principles); or just use a transpiler and ship un-nested stylesheets like they aready do today, and we don't need to bother with the feature.

`@supports (@nest)` or `@supports at-rule(nest)` would be trivial to add and obvious to authors. We currently don't have a good answer how to feature detect the look-ahead version. So this is a factor to consider.


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


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

Received on Saturday, 8 April 2023 23:35:52 UTC