[css-nesting-1] & representing parent elements vs parent selector

[tabatkins]

When I wrote the Nesting spec originally, I specifically defined it so that & was an ordinary selector, that happened to match the elements matched by the parent rule. This leveraged the powers that only a live browser could have, which seemed useful. Preprocessors, unable to do the same, instead have to make their "nesting selector" more of a macro, that is substituted with the parent selector.

That is, in a rule like

.a .b {
  .c & {...}
}

In the Nesting spec, the & matches "a .b element with a .a ancestor", and the nested rule imposes an additional "...and has a .c ancestor", so it's the equivalent of .c :is(.a .b). It'll match all the following markup structures:

<div class=a>
 <div class=c>
  <span class=b></span>
 </div>
</div>

<div class=c>
 <div class=a>
  <span class=b></span>
 </div>
</div>

<div class="a c">
 <span class=b></span>
</div>

Preprocessors can't do this (or rather, couldn't do this before :is() was standardized, and still can't widely do it since support for :is() is still in the low 90%s). Expanding such a selector fully (to .a .c .b, .c .a .b, .a.c .b) would mean a combinatorial explosion in selector length, and gets drastically worse the more combinators are in either selector. (Sass has a similar situation with its @extend rule, where it uses heuristics to select only a few likely expansions, rather than all possible ones.) Instead, they substitute the selector directly, giving .c .a .b, and only matching the second of those three markup structures.

I was discussing Nesting with @nex3 a few days ago, and she expressed surprise and some dismay that Nesting had this behavior. She believes that a large amount of CSS written with Sass nesting expects and depends on the current Sass behavior, not accidentally but quite intentionally - they expect this sort of nesting pattern to be expressing "and then a .c container around the previous stuff" rather than just "and then a .c container somewhere around the specific previous elements". She believes this would actually be a significant burden to people migrating from preprocessor nesting to native nesting, and even for people who are using native Nesting fresh, believes it'll be a common point of confusion for people using this pattern.

As well, under Sass's behavior, an author can recover the current spec's behavior by wrapping the & in an :is(), like .c :is(&) (or wrapping the parent selector). However, there is no way to recover Sass's behavior from the current spec's behavior.

In the majority of cases it doesn't make a difference which way we go. The most common relative selector case (a nested selector like .c or + .c) is unchanged, and many non-relative selectors are also unchanged, such as & + & or :not(&). Only cases like the above, where there is a descendant combinator in the parent selector and a descendant combinator in the nested selector with an & following it, will change their behavior.

I know this is a pretty significant semantic change to be coming at this late time, but Natalie felt it was pretty important, and @mirisuzanne backed her up, and the arguments were reasonably convincing to me.

(Note: we'd still not be doing selector concatenation - .foo { &bar {...}} is still equivalent to bar.foo, not .foobar.)

[mirisuzanne]

Yes, I've had use-cases for both selectors – but the desire to 'scope the outer selector entirely' (.c .a .b in the example above) is by far the majority use-case in my experience, and what I would expect from reading the selector. I would find it fairly surprising to get the .c :is(.a .b) behavior without specifically requesting it. And I'd have a strong leaning towards the semantics that allow expressing both variations explicitly, rather than implicitly using the more broad selector without any way to clarify.

I am curious how the css-nesting polyfills in other processors have handled this. Were those polyfills designed with the current spec behavior, and has that resulted in surprising selectors for people?

(While I'm curious about that, I don't think it necessarily tells us if the pattern is safe. In a lot of cases, I would expect the DOM will only have .c .a .b matches, even when the output selector is .c :is(.a .b). That wouldn't make it safe to implement the less expected behavior, it would actually point to the idea that one case is much more common. I don't think that's something we could measure. So the question is really: are people explicitly expecting and relying on the .c :is(.a .b) pattern when writing .c & in one of those polyfills?)

[romainmenke]

I am a bit surprised to see this come up here :)

I've reached out on the Sass repo to bring up exactly this difference : sass/sass#3030 (comment)

I've also brought this up each time someone advertised Option 3 as a syntax option that is like Sass and would be simple to migrate. It is not simple exactly because of this difference.

---

I am curious how the css-nesting polyfills in other processors have handled this. Were those polyfills designed with the current spec behavior, and has that resulted in surprising selectors for people?

In postcss-preset-env we follow the specification with postcss-nesting.

We have heuristics to mimic what :is() would match without actually using :is() for some common and simple patterns. For all others we use :is().

We've learned that people do not (yet) have a good mental model for :is() when complex selectors are involved. Nesting ultimately follows similar rules as :is(). We've had multiple bug reports because we follow the specification.

Especially people coming from Sass have greater difficulty switching to "native nesting".
We've spend quite a bit of time educating people about the nesting specification, :is() and how it differs from Sass.

Those without a prior mental model seem to intuitively figure out what works and how to use nesting.

[Loirooriol]

How is & + & unchanged? If SASS substitutes the selector, with a parent of .a .b, & + & becomes .a .b + .a .b, which is different than :is(.a .b) + :is(.a .b) a.k.a. .a .b + .b.

Seems to me this happens when the parent and nested selector are complex, and the latter uses & after a combinator. Descendant combinators are not needed at all: .a + .b { .c + & {} } is .c + .a + .b in SASS, and .a.c + .b in CSS.

[tabatkins]

You're right, it does change. Specifically,

.a .b , .c .d {
    & + & { color: blue; }
}

becomes

.a .b + .a .b, .a .b + .c .d, .c .d + .a .b, .c .d + .c .d {
  color: blue;
}

in Sass.

[romainmenke]

In Sass it is also perfectly fine to use pseudo elements in the parent :

::before, ::after {
    color: cyan;

    @media (min-width: 300px) {
        color: lime;
    }

    &:hover {
        color: pink;
    }
}

Not having this feature seems problematic for many.

[Loirooriol]

My thoughts are:

• Follow this principle: https://w3ctag.github.io/design-principles/#third-party-tools. Usability takes precedence over compatibility with tools, and I'm concerned that the combinatorial explosion will make nesting unusable except in trivial tiny cases.
• What SASS is doing seems a bad and confusing design to me, since it's not just replacing & with the parent selector:
  • Top-level selector lists are split and not handled as a single selector. This has e.g. the implication that wrapping a selector list inside :is() in order to have forgiving parsing will change the meaning in nesting
  • What about nesting .c& inside .a .b, the spec allows it, seems invalid in SASS, would it produce .c.a .b with this proposal? Regardless, .c& looks like a compound selector but it can't be freely reordered.
• The current spec is more natural to CSS. May it be confusing to the people who are used to a tool with a different behavior? Sure, but of course they are biased.

[cdoublev]

As Oriol noted, a consequence of resolving & with :is() is implicit forgiving parsing whereas parsing the top-level selector is not forgiving, which can be surprising for authors. For example, html|:hover, .class:hover {} would be invalid and entirely ignored, whereas :hover { html|&, .class& {} } is valid and apply styles on elements matching .class:hover.

I take this example on purpose because if & must be resolved with :is(), I think it should not be allowed to replace any symbol produced by <compound-selector>. For example, div { [title=&] {} } would also be valid. & should only be allowed to replace <simple-selector> (<type-selector> and <subclass-selector>), <pseudo-element-selector> and <pseudo-class-selector>.

On the other hand (also noted by Oriol), I am not sure whether :hover { &.class {} } should be valid if it is not resolved with :is().

[tabatkins]

Usability takes precedence over compatibility with tools, and I'm concerned that the combinatorial explosion will make nesting unusable except in trivial tiny cases.

Given that Sass has been shipping with this exact behavior for years, and they pay a larger cost than browsers would (Sass has to ship the expanded results over the wire, rather than just representing it in memory), I don't believe this fear is warranted. (It does make the need for a minimum/maximum spec more relevant, as in #2881.)

Top-level selector lists are split and not handled as a single selector. This has e.g. the implication that wrapping a selector list inside :is() in order to have forgiving parsing will change the meaning in nesting

This is true. But note that "just wrap it in :is() is already noted to not just be a forgiving no-op; note its effects in :has(). Increasing the places where this is true isn't great, I agree.

What about nesting .c& inside .a .b, the spec allows it, seems invalid in SASS, would it produce .c.a .b with this proposal? Regardless, .c& looks like a compound selector but it can't be freely reordered.

Sass's particular parsing/emitting rules disallow .c& as invalid; you have to write it as &.c. That's not a requirement for us, tho; I imagine Sass's limitation is related to their support for token concatenation.

So no, .a .b { .c& {...}} would still effectively produce .a .b.c {...}. The rule is "the compound selector with the & is merged with the final compound selector of the parent; compounds preceding the & are placed entirely before the parent selector, while compounds following the & are placed entirely after".

The current spec is more natural to CSS. May it be confusing to the people who are used to a tool with a different behavior? Sure, but of course they are biased.

Right, that's the question - is the expectation formed by Sass authors the natural expectation, such that we can expect fresh CSS authors to do the same, and be surprised when they write HTML that violates that expectation but still matches? (Like markup options 1 and 3 in my original post.) I think that it's a somewhat reasonable expectation.

And again, since it's quite easy to regain the current spec's behavior (by using :is(&)) if we make this change, but impossible to gain the Sass-ish behavior if we retain the current spec, I think the threshold for reasonableness is lower than it would be if we were deciding entirely on one vs the other.

For example, div { [title=&] {} } would also be valid.

This definitely would not be. The & is still, itself, a <simple-selector> for grammar purposes.

In Sass it is also perfectly fine to use pseudo elements in the parent :

Yes, this would make pseudo-elements in the parent usable again.

[tabatkins]

Summarizing some pro/cons of each:

The Current Spec

• Pro: Seems more "CSS-ish", using CSS concepts and the dynamism of the browser more fully
• Pro: Works better for sibling combinators. .a .b { .c + & {...}} does what it looks like (matches when the element's previous sibling is .c).
• Con: .a .b { .c & {...}} matches in more cases, which can be unexpected, and there's no way to enforce ".c is an ancestor of the entire parent selector" semantics.
• Con: Until we add some way for pseudo-elements to work in :is(), this is fundamentally incompatible with pseudo-elements in the parent selector.

The Sass-ish Proposal

• Pro: Might match author intuition better in cases like .a .b { .c & {...}}, where it means ".c is a container around everything I was doing in the parent selector" (rather than just ".c is an ancestor of the selected element, but might be higher, lower, or on the same element as .a").
• Pro: Works automatically with pseudo-elements, tho perhaps in a naive way - ::before { &:hover {...}} gives ::before:hover, but there's no way to apply conditions to the originating element (producing a selector like :hover::before, or something like .foo::before).
• Pro: can regain the current spec's semantics with :is(&).
• Con: Probably matches author intuition worse when used with the sibling combinators like in .a .b { .c + & {...}}, where it produces .c + .a .b. Usages like .a .b { & + & {...}} produce the nigh-nonsensical selector .a .b + .a .b, a complete departure from what the author appears to be saying in the nested selector (selecting an element when its previous sibling also matches the parent selector). (But as noted in the previous bullet point, :is(&) + :is(&) does do what's probably intended.)
• Con: depending on implementation, might add an additional multiplicative factor (equal to the number of complex selectors in the selector list) to the internal selector expansion (on top of the existing depth-based multiplication).

---

[Loirooriol]

Given that Sass has been shipping with this exact behavior for years, and they pay a larger cost

Correct me if I remember wrong, but I recall reading comments where you said that SASS avoids the combinatorial explosion by using some heuristics and not expanding to the full list. This doesn't seem reasonable for CSS.

I don't believe this fear is warranted.

I would like to know what an implementer thinks @sesse

[romainmenke]

I recall reading comments where you said that SASS avoids the combinatorial explosion by using some heuristics and not expanding to the full list.

It is also mentioned in the note under :

Why is the specificity different than non-nested rules?

https://drafts.csswg.org/css-nesting/#:~:text=Why%20is%20the%20specificity%20different%20than%20non%2Dnested%20rules%3F

Happens to be the same note I was looking for regarding specificity

---

Would specificity remain the same as if :is() were used?
i.e. only the matching behavior would change

---

:not() would behave differently from an author perspective.
I can't estimate if this would ever be an issue in real world cases.

.c .a .b

.a .b {
  .c & {}
}

.c :not(.a .b)

.a .b {
  .c :not(&) {}
}

[sesse]

I would like to know what an implementer thinks @sesse

It's a bit tricky to comment on this, because I don't think the boundaries of the proposal really have been fully laid out yet. So let me first assume that we don't mean to support token pasting (e.g. .foo { &_bar { … }} becoming .foo_bar { … }.

Second, do we intend to do this expansion before or after CSSOM?

Let me give a very short introduction to how CSS selectors work in Chromium, to the point over oversimplification. We store two different representation of a stylesheet in memory, where one is roughly an array (for parsing and CSSOM purposes) and the other is roughly a hash table (for matching purposes). The former looks very much like what you'd write in a stylesheet, which the notable exception that selectors with selector lists are parsed into a tree structure and the combinator set is a bit more explicit (each and every simple selector has a combinator towards the next element). E.g., if you write .a .b:is(.c, .d), what you get is basically .a <descendant> .b <subselector> :is(<mumble>) <end-of-complex-selector-list>, where the <mumble> part is a pointer in memory to another selector list (.c <end-of-complex-selector> .d <end-of-complex-selector-list>).

The second, which we actually use for matching, uses the same complex selector representation, but is otherwise completely different. In particular, this representation rests pretty firmly on the concept of the (complex) selector as a unit; if an author writes .a, #id { … } in the former, that becomes two entirely distinct rules in the latter. We also store some information like hashes of ancestor elements (for quick rejection of rules where the subject matches but the ancestors do not) in this representation, and the original flat array is completely broken up and is scattered in bits and pieces.

Supporting the current spec is super-simple for us. Whenever we see &, we treat is nearly identical to an :is(<mumble>) selector; it's just that instead of following the pointer to a new list, we store the pointer to the parent rule instead, and when it's time to match, we just go to its selector list, just as if we had an :is. Nearly everything else falls out of that; specificity, parent rejection, and so on.

Now let's look at the case where we are to treat & as just a selector list paste, under the example in question. There are basically two options here; expanding the selectors during the conversion from the first to the second form, or not. Let's look at the second first. Consider a case such as .a { .b & .c { … }}. The inner rule would be stored as . b <descendant> & .c <end-of-complex-selector-list>. So when matching, generating specificy, descendant hashes etc., we'd need to see the &, make a sort-of goto (or gosub!) jump into the upper rule, and then when seeing the end of the complex selector list in the parent, jump back. This is possible, but it's going to be pretty slow; right now, moving along this list is extremely fast (always just a pointer add), and now we'd introduce a branch. It's feasible, but it would slow down selector handling universally for us.

However, the bigger problem here is selector lists in the parent. I can't find any usable ways of dealing with that at all. Not only would we need to know ahead of time that we'd need to start matching of the inner rule twice, and then know which of the two parents to jump to; we wouldn't know where to store the rule in the first place. (We absolutely need two selectors .a and #id to be stored different places; where would we store & { … } if the parent was .a, #id { }?)

So we need to expand; there's no way around it. I see that people think this is a lower cost for us than Sass, but it absolutely isn't. The wire cost is real, but it can be compressed, and our memory representation is going to be much larger than what you'd see on the wire even without compression—and Sass only needs to run once, whereas we'd pay the CPU costs on load (when we recreate the second form, either due to load or a stylesheet change) and the RAM cost for as long as the page is loaded. I also see people claim that both the current spec and an expansion-like form are “multiplicative”, but that is entirely wrong; the current spec is additive (n rules always cost O(n) memory, O(n) setup cost and usually O(1) match cost—O(n) at most) and expansion is indeed multiplicative, leading to exponential behavior when chained (n rules can cost O(2^n) memory, O(2^n) setup cost—match cost is still usually O(1), but now O(2^n) at most).

Authors already know next to nothing about style performance. If you give them this kind of behavior, it's just a huge footgun, and there's no way they will understand that their innocent CSS blows up completely in the browser.

We could try to put limits on this, but it's not entirely clear how that would work. Where would these limits be enforced? What would happen if they are violated; would rules stop matching silently? What happens when some of the rules get modified in CSSOM; does the modification fail, or does something else happen?

If we didn't have complex selector lists in the parent, we wouldn't have these problems. We could expand; it would cost us some memory and be a bit slower in the setup phase, but it would be restricted to rules that actually use nesting. Even without parent lists, I don't really think trying to match & directly by goto/gosub would be a very attractive option, for speed reasons (and I can imagine WebKit's JITing of selectors would also potentially run into issues here, without ever having looked much at their JIT).

The third alternative is the infamous Sass heuristics, but if so, someone would have to specify what those are if we are to discuss them. And again, remember that they'd have to be efficiently implementable very quickly (whenever a stylesheet loads or changes), so it's not a given that we can just copy Sass' implementation.

As a separate note, it is a problem to try to radically change the spec basically at the moment we are trying to ship it. This is a great way to discourage people from being the first to ship a feature.

[jakearchibald]

fwiw, I posted a couple of polls on the topic: Twitter thread, Mastodon thread.