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

> [ideas about delimiter-based nesting]

I'm strongly against ideas in this form. It's a parsing mode switch, which is slightly awkward technically but not killer, but it means that the parsing context you're in is less obvious, which isn't great for authors. It's also very awkward to manipulate with the OM - are those at-rules that should show up in the OM? If so, what happens when you move them into a bad order? Or are they just syntactic indicators that don't show up in the OM at all?

> [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. 

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").

-----

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. (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). But that's not relevant for this topic, which is about how to allow nested rules alongside properties.)

The current spec (allowing naked nesting if the selector starts with `&`, or `@nest`-prefixed for arbitrary selectors) does this, at the cost of requiring authors to make a *local* check on their selector so they know whether an `@nest` is required or not. My preferred alternative in this thread (just always use `@nest`) also does this; it's better in that authors don't have to think about their selectors, but worse in that they have to write one extra token per rule.

Nothing else in this thread has done this; every single suggestion diverges, sometimes *significantly*, from the nesting syntax authors are already familiar with. They also all have their own drawbacks, ranging from extra indentation, to not actually being nested at all, to having to track non-local information about parser modes, to making OM manipulation much more complicated. All of them are trying to avoid just adding `@nest` to every rule, but I think the drawbacks all end up *significantly worse*. 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.

Finally, from a theoretical purity standpoint, the less "weird" we can make parsing, the better. Any novel approaches require the Syntax spec to be modified, and make it more likely there will be incompatibilities attempting to use this syntax in any other context (nesting in style attributes, for instance). I already had to put a new rule into the Syntax spec to accommodate the *current* Nesting spec (branching on whether I see an `&` or not), and switching to "always `@nest`" would let me drop that and go back to the dead-simple parsing that CSS currently relies on; that makes it really attractive to me. (It also would mean I don't have to do funky things to rule serialization, deciding whether to prepend `@nest` or not depending on whether the selector is valid to be used nakedly.) The more regular, consistent, and predictable CSS syntax is, the better it is for both authors (they won't have to learn as many context-specific parsing rules, which CSS is *already* overloaded with) *and* us future spec writers (we won't need to engineer around our past decisions when they're awkward in a new context).

I think we should keep things simple, and keep things CSS-y. We should just use the `@nest` rule.

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4748#issuecomment-966513828 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 18:08:07 UTC