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

I’m unsure whether to mark myself as preferring option 3.

From [the description](https://github.com/w3c/csswg-drafts/blob/main/css-nesting-1/proposals.md#summary-of-nesting-proposals) of option 3:
> No parsing switch

I could support this, as I would prefer not to introduce new kinds of parsing states.

> instead every nested rule has to be unambiguous on its own

I strongly support this, as it makes each rule feel more portable and self-sufficient.

> by starting with anything but an ident.

I do not support this, as I could easily imagine future non-ident rules that should work differently. Ones that immediately come to mind are [`@if`](https://github.com/w3c/csswg-drafts/issues/5624) and [`@extend`](https://github.com/w3c/csswg-drafts/issues/1855), and possibly some future version of `@apply`.

If there is a strong desire for minimal-but-strict parsing semantics, I would strongly recommend using only a very limited set of delimiters. I would propose supporting only one at first.

I would support limiting nesting to `@`-like rules. Using a [bare `@`](https://github.com/w3c/csswg-drafts/issues/5746#issuecomment-739099532) has been mused, and it has received [positive](https://github.com/w3c/csswg-drafts/issues/4748#issuecomment-929606825) and [negative](https://github.com/w3c/csswg-drafts/issues/5746#issuecomment-746557911) signals.

```css
.notification {
 color: blue;

 @ .context & {
  color: green;
 }
}
```

For better or worse, a bare `@` at-rule would either be a wonderful or confusing way to work around [descendant combinators](https://drafts.csswg.org/selectors/#descendant-combinators) in nesting rules.

An example applicable to [this recently popular CSS tweet](https://twitter.com/chriscoyier/status/1581028619907788800):
```css
.bubble {
 @:has(> &) {
  --triangle: down;
 }

 @::after {
  @container style(--triangle: down) {
   content: " injected";
   background: lime;
  }
 }
}
```

Another example applicable to [this recent message](https://github.com/w3c/csswg-drafts/issues/7834#issuecomment-1268979633):
```css
.main-nav {
 display: flex;

 @ ul {
  list-style-type: none;

  @ li {
   margin: 0;
   padding: 0;
  }

  @ a {
   display: flex;
   padding: 0.5em 1em;
  }
 }
 
 @ &nav {
  display: block;
 }
}
```

Another advantage to limiting nesting to an `@` symbol would be that it provides a strong and consistent signal to developers.

One last contrived example where I attempt to deliberately make it look bad, if it doesn’t already, and despite the fact that I really would support a bare `@` symbol.
```css
button {
 @:hover {
  color: black
 }
 @&:hover {
  color: black
 }
 @:is(:hover) {
  color: black
 }
 @&:is(:hover) {
  color: black
 }
 @&:is(&:hover) {
  color: black
 }
}
```

**Note**: In all of the provided examples where the bare `@` is followed by a non-space character, the bare `@` is never being interpreted as the nesting selector (`&`). Rather, if we decided to infer `&` when none is present, and if we decided to honor the absence of any descendant combinator space following the `@` delimiter, then we would just get this (helpful, I think) behavior for free.

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


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

Received on Wednesday, 19 October 2022 05:03:13 UTC