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

This seems like a pretty important feature to get right, and having read [https://lists.w3.org/Archives/Public/www-style/2021Nov/0000.html](the minutes) of a recent meeting, I'm very surprised that everyone but tabatkins preferred `{}` over `@nest`. I, like tabatkins, feel very strongly that extra nesting will be quite inconvenient to read, write and maintain.

I'm actually a fan of this syntax suggested by LeaVerou earlier:
```scss
.rocket {
    --engine: super-blasting;
    color: white;
    content: "astronaut";
    
    @nest;
    & .engine { color: gray; }
    & .window { color: transparent; }
}
```
This, as mentioned above, involves a parser mode switch, which tabatkins has some concerns about, primarily these two points:
> it means that the parsing context you're in is less obvious, which isn't great for authors

I'm not so sure where this is coming from. I'm going to naively assume that people will use indentation for nested rules, and so the nesting itself would be apparent from that - either way, this seems no different from SCSS, and I doubt many people struggle with what parsing context they're in when writing or reading SCSS.

> It's also very awkward to manipulate with the OM

Okay, this one I understand a bit better, though (looking at the above example still) including the `@nest` in the OM would make no sense to me. As tabatkins mentioned before, something like
```scss
.foo {
    & .bar { color: red; }
    @nest .baz & { color: blue; }
}
```
would parse the nested rules

> As CSSStyleRule objects in the `.childRules` property of the parent rule.

This makes sense. Note how the `@nest` is not really an at-rule in the OM. That would be weird; then either the rules are different, one being a `CSSStyleRule`, another being a `CSSNestRule` (or something along those lines), or even stranger, both would be `CSSNestRule`s even though the `& .bar` does not look like an at-rule at all. So, it only makes sense to me that the earlier syntax would parse, well, identical to the way that the spec would currently parse nested selectors. It would not include the `@nest;` in the OM; that's just something we write to say "okay, that was all my declarations for this selector, now here comes the nested selectors". I don't see any use case for it being useful to include the `@nest;` in the OM.

That being said, I actually don't mind the syntax that's currently in the spec, though I'm a bit worried about people who are new to CSS. Given most rules start with `&` (and they do for me; I wouldn't be surprised if beginners follow this as well) it'll probably cause quite a bit of confusion and annoyance for them to try to debug why their `.foo &` rule didn't work, and it'll probably not be clear to them why the `@nest` is needed in the first place (my selector contains an `&`, why can't it see that?). The current spec is carefully wiggling itself through the constrains that we have, and is doing so successfully, but the wiggling part of that is visible in the syntax, and anyone that's not familiar with or interested in parsers will probably be confused and annoyed with this syntax.

I think this would be slightly reduced by asking everyone to write `@nest` in front of every rule, but even then; "why can't it see my selector contains an &?" is probably going to be a question floating around in people's minds quite a bit (it would for me, anyway). The syntax I mentioned before, with a `@nest;` delimiter between declarations and nested rules however, doesn't quite suffer from this problem as much. It's far less annoying to write it once than every rule, and a lot easier to explain to beginners why it's needed: "it's to separate the declarations and the nested rules" would satisfy me if I just started learning CSS.

Lastly, I just want to repeat that I'm absolutely wholeheartedly against more indentation (i.e. using extra `{}` to denote nested rules). "Just stop using 4 spaces" sounds to me like essentially the same argument as "just write `@nest` in front of every rule" - sure, yes, I could stop using 4 spaces, but I prefer not to because it helps me understand code. The extra indentation, as well as the towers of curly braces it comes with, look messy to me, and as tabatkins mentioned before, it'd be quite inconvenient when editing styles (specifically going from a purely nested rule to one that also has some declarations or vice versa). Especially after seeing some real-world conversions of nested styles to the `{}`-syntax, I would be sad to see the long awaited feature, nesting, becoming a reality in this way.

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


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

Received on Friday, 12 November 2021 11:04:10 UTC