[css-nesting-1] Should prefixing nested selectors be mandatory?

[SebastianZ]

As mentioned in #8248, some people expressed support for making the ampersand in nested rule selectors mandatory. Some discussion already happened in the other issue, though here's a summary of its advantages and disadvantages:

Advantages:

• Clarity for authors and readers (e.g. &::before vs. & ::before)
• Allows support for full selector syntax (including type selectors)
• Lets UAs still distinguish selectors from property declarations on the first character even with type selector support

Disadvantages:

• Confusing for authors when using & later in the selector (in case & is used as prefix and reference for elements matched by the parent rule)
• More to write for authors
• Unnecessary regarding parsing (except for type selectors)

Sebastian

[tabatkins]

The "clarity for authors" argument appears to be completely theoretical. The current syntax is more or less what has been supported in many widely-used preprocessors for over a decade, and there doesn't seem to have been any significant confusion on author's parts. We're not exploring new space here; this is a well-trod cowpath.

Using the & as the mandatory prefix as well as a nesting selector is absolutely a no-go - that is legitimately extremely confusing that .foo { & .bar & {...}} is actually equivalent to .bar .foo {...}, when .foo { & .bar {...}} is equivalent to .foo .bar. The similar case in the current syntax (.foo { .bar & {...}} and .foo { .bar {...}}) isn't as confusing because the & only means one thing the whole time; you can't read the latter example and assume that the & is acting as a nesting selector (while it's actually just a meaningless prefix in the suggested mandatory-& syntax) because it simply doesn't appear at all.

If we were to go with mandatory prefixing we'd use @nest (as in one of the rejected earlier options) or just @.

[jensimmons]

Requiring & will not work, since the & character will be used for usecases like this:

section {
  article  &  {
     color: black;
  }
}

which results in article section { color: black; }. Alternatively section { & article & { would result in section article section {, which is a very different result.

There has been discussion of using a different symbol. Keep & as is. And use something else, like @, *, or @nest instead. Like this: section { * article & { — see #8253 for a discussion of allowing * optionally.

The CSSWG has discussed mandating a prefix (whichever the character) quite a bit already. And settled on no — because we value author's ability to more easily copy & paste code in/out of a nested context.

All that said, I believe we should not make prefixing nested selectors mandatory because of the Robustness principle (also known as Postel's law): "be conservative in what you send, be liberal in what you accept".

Web technology has been designed with a set of principles in mind, to rely on when debating questions exactly like this one. Some developers want the mandatory symbol, others do not. So which is the right choice? We could debate pros & cons forever and still not agree. Underlying design principles are the right place to look to guide decisions in such situations.

According to the Robustness principle, CSS should lean towards more flexibility in how authors write their selectors, not less. If they want to always use a & (or perhaps *), great. If they don't, great. It's up to them, their tech leads, their linter. The browser should be liberal in what it accepts.

I do not believe we should violate the Robustness principle for this case.

[Alohci]

My understanding of the "require & prefix" idea is that & at the start only substitutes to :is(parent-selector) if it is the only & in the nested selector, otherwise it substitutes to nothing. So:

section { & article { ... } }
maps to section article while
section { & article & { ... } }
maps to article section
If you wanted section article section you'd have to write
section { & & article & { ... } }
which works mechanically, but to me feels very confusing.

And I agree that the Robustness principle should be the guide.

[fantasai]

The CSSWG already discussed and rejected prefixing every rule, see https://lists.w3.org/Archives/Public/www-style/2022Oct/0022.html @SebastianZ is there some new information that you wanted to bring to the table that requires re-opening that question?