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

> As the author of the Syntax spec, and the writer of a number of additional parsers for various languages, I know that. ^_^
> 
> But not all positional awareness is created equal. Knowing what parsing context you're in is important; it should be obvious and easy to determine, and ideally hard to accidentally flip. Your proposal doesn't satisfy this, I believe - it has three separate parsing contexts: properties, then a single rule starting with `&`, then any rule at all - and I think it's relatively easy to mess that up. Nested rules that are valid at one spot in a parent rule are _invalid_ in another spot; removing a rule (the first one that flips the context over) can invalidate rules coming afterward; etc.

I know you know that, that's why I was referencing it 😄 

The way I see it, it's super easy to flip context in most cases: insert a non-escaped quote in a string and boom, you're out of the string. Insert a `}` in a CSS declaration and boom, you're out of the rule. Same with most delimiters. 

> Your proposal is no different. Most Sass nesting, from what I can tell, does _not_ start with an `&`; they instead usually use relative selectors that start with a combinator (including, most commonly, the descendant combinator). 

Yes but `& ` is valid there, so they could be writing stylesheets today with the mindset of switching later.

> 
> > 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.
> 
> Then we can keep the current spec. ^_^

Yeah, I think that's the best compromise. It would certainly be unfortunate if this discussion results in *more* syntax, rather than less.

> If we use "always `@nest`", then we don't have _any_ parsing concerns, and could easily allow relative selectors instead (including implicit descendant combinator), because the prelude of an at-rule is wide-open in its syntax. We can't do that today because it would require us to add more parsing carve-outs for detecting a rule vs a property.

We can still have implicit descendant when `@nest` is used even if it's optional.

-- 
GitHub Notification of comment by LeaVerou
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4748#issuecomment-966975477 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 10:03:30 UTC