Re: [csswg-drafts] [css-nesting] Syntax suggestion (#4748)

Here's a slightly non-trivial example of Nesting usage, taken from [Bootstrap](https://github.com/twbs/bootstrap/blob/main/scss/_tables.scss), using just two levels of nesting:

Sass:
```scss
.table-bordered {
 > :not(caption) > * {
  border-width: $table-border-width 0;

  > * {
   border-width: 0 $table-border-width;
  }
 }
}
```

Here's it in the two modes:

{}-wrapped: 
```css
.table-bordered {
 {
  & > :not(caption) > * {
   border-width: $table-border-width 0;

   {
    & > * {
     border-width: 0 $table-border-width;
    }
   }
  }
 }
}
```

@nest-prefixed:
```css
.table-bordered {
 @nest & > :not(caption) > * {
  border-width: $table-border-width 0;

  @nest & > * {
   border-width: 0 $table-border-width;
  }
 }
}
```

Y'all are really okay with those *five levels of braces*? That looks good to y'all? If they'd gone down three levels, which is the limit that most styles guides recommend, it would be *seven*.

And yes, there are ways to format that to reduce the amount of indent, but they're either fragile or just as much effort as @nest.

If you go with "double-brace if you're just doing nesting", then you end up with:

```css
```css
.table-bordered {{
 & > :not(caption) > * {
  border-width: $table-border-width 0;

  {
   & > * {
    border-width: 0 $table-border-width;
   }
  }
 }
}}
```

But now you've got inconsistent styles even within this one rule, since the second level *does* apply a property and thus needs to brace normally. It also breaks the benefit cited by someone in the call (not captured in the minutes) of having even/odd indents indicate properties vs rules, since here both 0 and 1 indents are rules. Finally, now you've got non-local edits to make if you *do* decide that `.table-bordered` needs to apply some properties, since you now have to put the inner braces back on their own line and increase the indent of the entire rule, which seems both mildly annoying *and* easy to forget to do (especially if people are coming from a processor language that already support intermixed properties and nested rules, so it *looks* fine to their instincts).

Alternately, one can tight-wrap each individual nested rule:

```css
.table-bordered {
  {& > :not(caption) > * {
    border-width: $table-border-width 0;

    {& > * {
      border-width: 0 $table-border-width;
    }}
  }}
}
```

This avoids excessive indents, but now you're still having to prefix every nested rule with something (a single `{` rather than `@nest`), *and* you have to end the nested rules with the weird-to-my-CSS-eyes `}}`. At least my editor (Sublime) handles it well by default, but it still has an extremely weird smell to it. (And [@LeaVerou's complaint about selector lists feeling odd](https://github.com/w3c/csswg-drafts/issues/4748#issuecomment-940160175) would still apply here, since only the first selector in the list would have the `{` prefix.) (It also suffers from the other complaint someone voiced during the meeting, that the `@nest` syntax isn't valid at top-level. This isn't either.)

Finally, both of these are just *styles* that teams need to adopt, both of which are foreign to current CSS, all preprocessors, and every non-CSS braces-using programming language I'm familiar with. Nothing prevents people from continuing to use it in the double-indent, giant-stack-of-close-braces-for-moderate-nesting style shown in the first block at the top of this post, which is indeed exactly how that bracing style would be indented by default in most style guides I've ever seen.

Prefixing with `@nest` is a little different than what current preprocessors do, but using/formatting it according to standard CSS practices produces an easy to read and write appearance that should feel familiar to authors. If we *really* feel like the six characters of `@nest`-followed-by-a-space are *that* burdensome, we can shorten it to `@n` or something.

I just feel like trying to go with this extra-braces style will end up being a *major* mistake that we severely regret in the long term (and heck, probably in the short term, too). It's trying to optimize away something that's not that bad with something that's much, much worse.

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


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

Received on Friday, 5 November 2021 17:01:27 UTC