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

I've been very confused, like romainmenke, about some steps that were taken. The [Syntax suggestion](https://github.com/w3c/csswg-drafts/issues/4748) issue was promptly closed with a simple comment

> Closing as resolved.

However it looks to be a completely open-ended thread and it is not at all clear how this resolution was reached, and more importantly, what the resolution actually was.
And, when looking at this new thread, it doesn't seem like the syntax issue has been resolved even a little bit - it seems like we just somehow marked the previous issue as "resolved" just to continue the conversation here.

It would be great to get some clarification as to what happened so that people like myself can feel like they are up-to-date.

<hr>

In the previous issue, I advocated for a syntax that simply required `@nest;` before using nested rules. There were no additional requirements. In my opinion, it is absolutely _vital_ that syntax is clear and consistent. The suggestions seem to be _"well, you can just start nesting, unless your rule starts with a character that is not part of `&`, or `@` (some suggestions including all non-alphanumerical characters), then you either need to switch the order of the rules so that it does, or use an `@nest;`"_. There are some JavaScript APIs that are in a similar manner dependent on context; e.g. `document.all('foo')` could return an element with `id="foo"`, but also an element with `name="foo"`, and actually if there are multiple elements with `name="foo"` on the page, it returns an `HTMLCollection` with all of them. Of course, this is CSS, and so it is very different in nature than JavaScript, but I can't help noticing the similarities (and I'm sure most of us agree that the API design of `document.all` was not good). I would think it's much safer, usable and future-proof if we go with something much more simple, like the required `@nest;`.

Additionally, I think we're missing the point by trying to stay as close as possible to SCSS syntax. The way we're trying to do that is inevitably going to lead to situations where people _expect_ a piece of SCSS to just work, but it doesn't. Minimizing the additional effort to _convert_ a piece of SCSS to CSS is a valiant effort however but it does not mean we have to mimic SCSS's syntax. With the required `@nest;`, authors would be aware this is necessary for their CSS to be valid. They can copy-paste SCSS, they will add the `@nest;` if necessary, and there's no additional overhead of _"oh, should I be changing stuff here? Do the rules start with the right characters, or should I change their order?"_.

Let me also bring up a previous point; the context awareness. Some people have mentioned that authors should be able to just see what context they are in (which is important if we introduce a parser switch). Now, overall, I don't think the parser mode will be difficult to recognize (and people won't even really need to know about the parser switch or what that even means), because a rule is a rule and a declaration is just that. We've already been doing it in SCSS 
and other preprocessors for a long time, proving this is not hard for authors to get used to. However, with the current discussion and suggestions in mind, if I see
```scss
    .red { color: red; }
```
and change it to
```scss
    h1 { color: black; }
    .red { color: red; }
```

is this valid? Uh, well, that depends; what's above it? Conversely, if I see `.red { color: red; }`, can I just remove that? Well, that also depends; if it has a rule in front of it, then yes, but if it's the first rule, then then next rule should... Etcetera. In terms of syntax it's a nightmare of mental overhead.

That seems like quite a problem. With something trivial like a required `@nest;`, the answers to the questions are obvious. You need a `@nest;`, so the simple addition of a rule like above is allowed regardless of context. There is a rule already, therefore there is an `@nest;`, which means that yes, you're allowed to add a rule. If you see a rule like `.red { color: red; }`, sure, remove it. Your CSS is guaranteed to still be valid.

Lastly, I'm going to repeat a point I mentioned in the previous thread. I mentioned then 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.

and I think we're merely amplifying this by throwing even more "if this, then..., otherwise..." in the mix.

To avoid confusion, I do not think a required `@nest;` is "the" solution, but in my opinion, it ticks the most boxes of any suggestion so far. Specifically the simplicity and consistency that I believe is so important in language syntax is missing from many of the suggestions made in this thread.

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


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

Received on Monday, 10 October 2022 09:40:05 UTC