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

> Having a parser switch like that would be unprecedented in CSS

Yes, but nesting itself would be unprecedented too. Perhaps the tradeoff is worth it?

As for the comparisons to `@import` and `@layer`; I was referring to the visual syntax only. A point was raised that `@something (parameters){ /* code */ }` seemed to be the mold at-rules conform to, and I was merely providing examples that do not have `(parameters)` or `{ /* code */ }` blocks. I understand the differences in how they are treated.

Anyway, in an attempt to push this issue ever so slightly closer to resolved, I'd like to logically go through the options we have, with the assumption that we do not want to introduce new concepts such as parser switches.

Of course, for this syntax to be usable, it necessarily needs to be somewhat resembling SCSS nesting. People have been using that for a very long time, so it is familiar to them, and it's what they want in CSS. Now, let's say we have the following SCSS:
```scss
button {
    color: red;
    aside & { color: blue; }
}
```
In CSS, we will need to somehow distinguish the `aside &` from the `color`; we don't want to do nasty lookaheads and so inevitably the `@nest` at-rule is born. There are now two sensible, familiar options for the `@nest` rule: We have `@nest (selector) { /* declarations */ }`, or `@nest { /* rules */ }`. The former is what is currently in the spec, but with a quirk that you don't need to use `@nest` for rules starting with an `&`. The latter is essentially the double brackets syntax, although we dropped the `@nest` (which seems to me would be _more_ outrageous than adding a parser switch `@nest`, but that opinion is coming from a developer, not an implementer). Those are the options. We _cannot_ avoid needing `@nest` for every rule not starting with `&`, unless we use double brackets; and neither option is great.

My point here is, we can try to think of different syntaxes all day long, but the viable candidates are _extremely_ limited when it comes to syntax structures we already have, especially given constraints like "no lookaheads" and "no inconsistencies". The parser switch would be a massive change for parsers, yes. If implementers are against it, I would understand. But I haven't seen an implementer actually object to the idea.

In my opinion, the `@nest;` parser switch is, so far, the best candidate we have when it comes to usability of the language. When I think about it, the language is already called "Cascading Style Sheets"; having this parser switch actually fits quite well.



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


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

Received on Friday, 2 September 2022 03:35:54 UTC