https://github.com/w3c/csswg-drafts/issues/7834#issuecomment..., on this exact matter (chosen as a convenient starting point, after matters were already settled, but the whole issue is about it). By the time this poll was done, they had already decided not to consider mandatory-&, though I don’t really understand why (it’s pretty obvious to me that dividing into 3a and 3b would have been much more interesting than a couple of the other options which were straw men that no one was capable of taking seriously even if they tried).
https://github.com/w3c/csswg-drafts/issues/7961, about doing away with & in all cases for descendant selector (… which would be terrible for complexity and worst-case performance, and is only being considered because they already made things inconsistent by making & optional in every other case).
(I don’t like where it’s ended up, and consider requiring the & in all cases to be obviously materially superior, for both machine and human handling, and that there’s clear concrete advantage in having the requirement as an actual language rule rather than only a linter-enforced choice. People are far too hung up on exactly Sass syntax.)
> it would only make the parser's job easier
Mind you, it’s not a big difference; it’s just “if there’s no & in the selector, insert one and a descendant combinator at the start” in some shape, which could be as little as half a dozen lines of code net.
I agree with the rest, but requiring & won’t make it easier for syntax highlighting, because that & can be anywhere in the selector, not just the start; the & affects nothing in determining whether it’s a rule or a property.
I'm saying the "&" should be required _at the start_.
Perhaps controversial, I know. I realize this eliminates use cases like
em {
color: green;
li & {
color: red;
}
}
It's okay not to support these use cases. They're confusing because they break encapsulation; the rule that appears to be nested inside (in this case, color: red) is affected by an element on the outside (in this case, <li>).
Compare:
li {
color: blue;
}
em {
color: green;
li & {
color: red;
}
}
To:
em {
color: green;
}
li {
color: blue;
& em {
color: red;
}
}
The second structure is easier to understand, and in my opinion, the syntax should bias you toward writing it that way.
This functional limitation was eliminated from consideration long ago: it’s very common to want that functionality. There were options considered for still denoting nesting, e.g. start all nested chunks with @nest, but this was decided to be inconveniently verbose. I think & is safe from being inconveniently verbose, but you can’t sanely use that without the functional limitation.
On your example: nesting is not about the sort of encapsulation you think it is—that’s incidental at best. It’s perfectly reasonable to say “this chunk of styles is about <em> elements; and when they’re inside <li>, do this”. The specific example you’ve given is also unrealistic with all three rules touching the same property in this way and two mutually exclusive (that is, li and em cannot both match, in any DOM), and I wouldn’t want it written with nesting at all, but rather like this, for much-increased clarity:
li {
color: blue;
}
em {
color: green;
}
li em {
color: red;
}
Hmm, thanks for the food for thought. In my use of CSS, I rarely come across situations that would call for this, but I'll pay more note to the possibility they might come up.
https://twitter.com/LeaVerou/status/1580215877705687040, a poll about this specific matter (with links to other relevant polls which on the surface contradict this one).
https://github.com/w3c/csswg-drafts/issues/7834#issuecomment..., on this exact matter (chosen as a convenient starting point, after matters were already settled, but the whole issue is about it). By the time this poll was done, they had already decided not to consider mandatory-&, though I don’t really understand why (it’s pretty obvious to me that dividing into 3a and 3b would have been much more interesting than a couple of the other options which were straw men that no one was capable of taking seriously even if they tried).
https://github.com/w3c/csswg-drafts/issues/7961, about doing away with & in all cases for descendant selector (… which would be terrible for complexity and worst-case performance, and is only being considered because they already made things inconsistent by making & optional in every other case).
(I don’t like where it’s ended up, and consider requiring the & in all cases to be obviously materially superior, for both machine and human handling, and that there’s clear concrete advantage in having the requirement as an actual language rule rather than only a linter-enforced choice. People are far too hung up on exactly Sass syntax.)
> it would only make the parser's job easier
Mind you, it’s not a big difference; it’s just “if there’s no & in the selector, insert one and a descendant combinator at the start” in some shape, which could be as little as half a dozen lines of code net.