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

> > [first rule needs to start with `&`, after that you're free to use whatever]
> 
> This hits similar problems - it's a mode switch in the parser, which means your parsing context isn't obvious from local inspection. It also has OM issues - what happens when you write a correct nesting rule, then modify it in the OM to have a different selector that doesn't start with `&`? You can't change how you serialize it to make it work; you'd have to change how the _parent rule_ serializes, inserting a "phantom rule" to trigger the parsing-mode switch.

I’m not sure how this is different from starting with a selector that starts with `&` and then later modifying it in the OM to one that doesn't (without adding `@nest`). It's the same kind of positional awareness, just larger scale (rule list vs selector list of a single rule). In fact, it could even happen with the current syntax if you rearrange the selectors in a selector list (e.g. `&.button, .button-group > &` to `.button-group > &, &.button`. 

The part about serialization is annoying, but we could fix it by inserting a phantom rule regardless if there are nested rules. It's ugly, but far better to have serialization ugliness, than authoring ugliness.

> Even without the OM concerns, this is an editting footgun - if you _start_ with a valid stylesheet with nesting, but later modify the stylesheet to change the selector or add another rule, you have to be careful that you're not making the _first_ nested rule in a sequence no longer a valid start. This sort of positional awareness is easy to mess up (which is part of why we have coding styles like "put a comma after every entry in an array, including the last one").

The main point of this suggestion is that in most cases authors wouldn't have to think about it at all, most stylesheets would just naturally work. Also editors could highlight rules where the first one didn't start with a `&`, in the same way they highlight improperly nested strings.

Positional awareness is **everywhere**, that's how parsers work! The part of a declaration that is a property value is the part that comes *after* a comma. The code that comes _after_ a `(` or `{` is different than the code before it. The code that comes _after_ the `;` in a CSS rule begins another declaration. I don't see how "the code that comes after `&` (with the `&`) begins the set of nested rules" is that different.
Even with commas in arrays, nobody is making the point that every array _must_ start and end with a comma, just to prevent forgotten commas while editing. 

> Overall, these suggestions keep trying to reinvent something that's already been proven out - all existing preprocessors nest in a simple way, where rules can come after properties, at the same level, without having to pay attention to the syntax of the selector or anything like that. We're operating under _one_ additional restriction - we need parsing to be immediately unambiguous - but that's it, and I think it's reasonable to say that we should stick as close to the proven and well-established syntax as possible while addressing that one restriction. 

A lot of these suggestions (including mine) are trying to do the very opposite: make preprocessor code somewhat more compatible with CSS Nesting so that migration is less painful (both in terms of migrating existing stylesheets, as well as migrating muscle memory, which is much harder). 

> (Arguably we have a second restriction, which is that we don't want an "implicit &", both for page-perf reasons (implicit descendant selectors aren't great) and for footgun reasons (adding an `&` anywhere else can change the meaning of the entire selector).

Is this a theoretical concern or has anyone actually added a `&` somewhere in a selector and was surprised to find its meaning change? I've been using implicit descendants in Sass for years and never had this problem nor have I heard anyone have this problem.
The performance is the same if you're forced to just prepend with `& `, you're just hoping that it will get authors to use something else and not descendants. Given that authors already use descendants extensively even when no nesting is available and they have to type out everything by hand, I think your hopes there are a little misplaced. 
All that this mandatory `& ` is doing is causing extra hassle when migrating stylesheets from existing preprocessors and when people used to preprocessors use this syntax.
At this point I may even have used CSS Nesting (via PostCSS) *more* than I've used Sass in my life, and I *still* forget the `& ` and have to debug why my rule is being dropped. The fact that you're already nesting the { ... } blocks makes it feel like the extra `& ` is redundant unless you want to specify a different relationship. 
Even making it default to child would have been better than making it invalid IMO…

> My preferred alternative in this thread (just always use `@nest`) […]
> My (small) experience here adapting existing nested styles into the various versions also bears this out - "always `@nest`" is trivial to adapt to, while everything else requires more work and some eyeballing.

I would be **strongly** against making the syntax even more annoying than it is today by having to prefix everything with `@nest`. Having used it a lot, it's already a pain to add `&` and `@nest` as needed. The cognitive overhead of deciding whether `@nest` is needed is orders of magnitude smaller than the overhead of writing `@nest` (even with autocomplete) or filtering it out mentally when reading stylesheets. 

> Finally, from a theoretical purity standpoint, the less "weird" we can make parsing, the better. 

Designing syntax around parsing instead of **people** is completely the wrong kind of prioritization and a usability antipattern. Authors are above spec editors and authors are above implementors in the priority of constituencies. If certain syntax makes things significantly easier or faster for authors at the cost of complicating implementations or spec work, that in most cases is a worthy tradeoff.

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


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

Received on Thursday, 11 November 2021 19:49:45 UTC