Csswg-drafts: [css-nesting] Allow more direct nesting delimiters

[jonathantneal]

CSS Nesting avoids unbounded lookahead to tell whether a given bit of text is a declaration or the start of a style rule by requiring a single token of lookahead in its parsing. These tokens are either the <delim-token> or <at-keyword-token>. More specifically, the <delim-token> must have a value of &, and the <at-keyword-token> must have a value of nest.

May we expand the allowable value of the <delim-token> to include non-& values for descendant nesting?

Before this proposed change, here is a sample of allowable CSS (_from CSS Nesting: Example 4_):

.foo {
  color: blue;
  & > .bar { color: red; }
}

.foo, .bar {
  color: blue;
  & + .baz, &.qux { color: red; }
}

.foo {
  color: blue;
  & .bar, & .baz, & .qux { color: red; }
}

After this proposed change, here is an updated sample of allowable CSS:

.foo {
  color: blue;
  > .bar { color: red; }
}

.foo, .bar {
  color: blue;
  + .baz, &.qux { color: red; }
}

.foo {
  color: blue;
  .bar, .baz, .qux { color: red; }
}

This would further align syntactically-allowable CSS nesting with existing user-land CSS nesting (e.g. Stylis, Sass).

[tabatkins]

Allowing a relative selector is technically doable, syntactically. However, it makes for a more complex line between valid and invalid syntax - you can write a selector without using & if you're chaining off of it with anything other than a descendant combinator. In Sass and other languages, this is more consistent, since it defaults to chaining off the parent with a descendant combinator.

However, the final example is still syntactically ambiguous, because & can appear anywhere in the selector, and can appear multiple times. Is .foo .bar:not(&) meant to be descending from the parent as well, and thus actually equal to & .foo .bar:not(&)? Or is it a standalone selector, and the sole explicit & is intended to be the only parent reference? Both are valid and potentially reasonable. You can come up with heuristics for this, but they won't catch every valid case, and they make the syntax even more complex.

All together, these changes would make the syntax slightly more complicated, won't reach the goal of "act like Sass" due to the inability to do relative descendant combinators, and save authors precisely two characters (or in some cases, depending on how they write them, one).

[jonathantneal]

I agree. I hadn’t seen your note on Lea’s issue when I wrote this up. I may open another proposal to see if a plain @ delimiter could be used as a substitute for @nest. Unless you think that can be easily dismissed as well? While I’m sorry I hadn’t gotten to closing this, your response will help others who wonder the same thing. Thank you!

[LeaVerou]

I may open another proposal to see if a plain @ delimiter could be used as a substitute for @nest.

I would be opposed to a plain @, since there are many @rules that we've discussed adding inside CSSStyleDeclaration over time (e.g. @if or, the now defunct @apply are some that come to mind). Also, Nesting permits @media and @supports inside rules. A bare @ would look very confusing, like an authoring mistake.

As for the proposal discussed here, I have no strong opinion. I do agree that Nesting in its current state is a bit verbose given the frequency that nesting is used when it's allowed (e.g. preprocessors), which is hundreds of times per sheet. However, I would rather we focus on cases where we can get rid of @nest (5 characters if you include the space) than getting rid of one & character.

[jonathantneal]

First, wow, thank you for responding to this idea, even before I made the issue. 🙏

A bare @ would look very confusing, like an authoring mistake.

Ah, that’s helpful to know. Where I had expected anyone to see an @ as “_a kind of nesting_”, I had not considered the potential for it to be seen as a kind of mistake.

However, I would rather we focus on cases where we can get rid of @nest (5 characters if you include the space) than getting rid of one & character.

Excellent. I’m all in favor of &. I’ll close this and do my best to contribute where I see other nesting discussions.