[css-nesting-1] Wrapping parent selectors with `:is()` introduces a host of problems

[LeaVerou]

Opening per action item in today’s telcon ( #8738 (comment) )

Problem

We currently desugar every nested rule using :is(), even when it’s completely redundant. E.g. this:

.foo, #bar {
	& {
		color: red;
	}
}

apparently becomes:

:is(.foo, #bar) {
	color: red;
}

This is not only redundant, it actually has observable side effects: since :is() has a flat specificity equal to the specificity of its argument with the highest specificity, the second rule is not equivalent to the first.

But even worse, because :is() cannot do pseudo-elements, it means this doesn’t work at all:

.foo::before {
	padding: 1em;
	@media (width < 500px) {
		padding: .5em;
	}
}

It would be rewritten like:

.foo::before {
	padding: 1em;
}

@media (width < 500px) {
	:is(.foo::before) {
		padding: .5em;
	}
}

which is invalid.

It also means we cannot fix #8738 by wrapping bare declarations after rules in & {} because in pseudo-elements they could be ignored.

Proposed solution

Edit: I'm not in favor of this any more, see #9492 (comment)

& {} should have no observable side effects. There is never a case where & needs :is() to be rewritten, so adding it not only introduces the problems discussed above, but is entirely redundant.

So a quick fix to the pressing issues could be to simply special case &.

Later down the line, we may want to consider expanding the set of cases that don’t require :is() because there is no danger of combinatorial explosion. From a quick call with @fantasai it seems to us that e.g. cases where there are only simple selectors all the way up would not need :is(), but more research is needed.

[Loirooriol]

I just want to note that & is not actually replaced by :is(), it just behaves like it.

The actual definition of & in https://drafts.csswg.org/css-nesting/#nest-selector

the nesting selector represents the elements matched by the parent rule

I guess this could become

the nesting selector represents the elements or pseudo-elements matched by the parent rule

I'm not convinced that the specificity needs to be changed.

Treating a & alone different than when used in a more complex selector seems extremely hacky and a source of confusion to me.

[andruud]

So a quick fix to the pressing issues could be to simply special case &.

Honest question: what's the pressing issue? Pseudo-elements don't currently work, but it seems fine to have a restriction that we can lift later? I hope we can avoid panic/"quick fixes", and instead accept that this doesn't work until pseudo-elements actually work within :is().

I'm not convinced that the specificity needs to be changed.

Right, if we want to change that, it seems more pressing. It might be too late already.

Treating a & alone different than when used in a more complex selector seems extremely hacky and a source of confusion to me.

+1

Maybe we can imply a new thing around bare declarations instead of &, that behaves as if the parent rule's selector list was used directly (unwrapped), and that also serializes as that selector list?

[LeaVerou]

@Loirooriol

I'm not convinced that the specificity needs to be changed.

I don’t think anybody is arguing for that — probably way too late due to web compat, and also unclear how it could be changed. There’s a reason :is() flattens specificity.

@andruud

So a quick fix to the pressing issues could be to simply special case &.

Honest question: what's the pressing issue? Pseudo-elements don't currently work, but it seems fine to have a restriction that we can lift later?

#8738 is the pressing issue, not pseudo-elements. See resolution & minutes from yesterday. The thing is, #8738 cannot be addressed without fixing the pseudo-element case (see minutes for details).

Treating a & alone different than when used in a more complex selector seems extremely hacky and a source of confusion to me.

+1

Maybe special casing & is hacky, but not wrapping hierarchies of simple selectors seems like a direct improvement, akin to e.g. not using parens when parens are not needed when generating expressions. :is() are basically the parens of CSS selectors.

[andruud]

OK. Hopefully it's not already too late to carry out #8738.

Maybe special casing & is hacky, but not wrapping hierarchies of simple selectors seems like a direct improvement, akin to e.g. not using parens when parens are not needed when generating expressions. :is() are basically the parens of CSS selectors.

Not only an improvement, it makes &'s behavior inconsistent. Removing parens that do nothing isn't the same as removing &/:is() which does do something.

We should wrap affected declarations in something which isn't &, if we don't want the behavior of &.

[tabatkins]

Yes, the :is()-like behavior is necessary to avoid inconsistent behavior. &, &.foo, & .foo, and .foo & should all be identical wrt specificity (well, the first will have one class less, obvs). We absolutely should not try to do anything to "fix" this in some of the cases but not others.

The pseudo-element restriction is annoying, but there's already an issue tracking that (#7433).

[tabatkins]

OK. Hopefully it's not already too late to carry out #8738.

For it to be "too late" it would require authors to (a) be writing decls after blocks, and (b) be depending on the "shift up" behavior differences (specificity and pseudo-elements). I suspect that's extremely unlikely.

[tabatkins]

Actually, let me make this clearer: I will formally object to treating & {...} differently from & .foo {...}.

Happy to work on the issues via some other mechanism (like Anders says, wrapping them in a different kind of rule instead - let's re-re-revive @nest!), but I'm absolutely not ok with having different behavior based on the exact selector used.

Do we want to repurpose this thread to discussing how to solve the "naked property nesting inherits some of Nesting's weaknesses" issue, or open a fresh issue?

[LeaVerou]

@tabatkins

Yes, the :is()-like behavior is necessary to avoid inconsistent behavior. &, &.foo, & .foo, and .foo & should all be identical wrt specificity (well, the first will have one class less, obvs). We absolutely should not try to do anything to "fix" this in some of the cases but not others.

The way :is() flattens specificity is a wart that was necessary because a pseudo-class needs to have a defined specificity, it cannot depend on what is matched. :is() is necessary for nesting to avoid combinatorial explosion, but I don't see why we should introduce this wart any more than is necessary (and where it is necessary can be statically determined at parse time).

The pseudo-element restriction is annoying, but there's already an issue tracking that (#7433).

That issue is closed. If we want to have an issue for tracking this, it should not be a closed issue.

OK. Hopefully it's not already too late to carry out #8738.

For it to be "too late" it would require authors to (a) be writing decls after blocks, and (b) be depending on the "shift up" behavior differences (specificity and pseudo-elements). I suspect that's extremely unlikely.

As was discussed in the telcon, authors absolutely do write declarations after blocks, though depending on the shifting up behavior is way more rare. FWIW I agree it's not too late to change this.

Actually, let me make this clearer: I will formally object to treating & {...} differently from & .foo {...}.

It may help to explain your reasoning rather than just vetoing things.

FWIW I was seriously considering formally objecting to keeping the shifting up behavior (the closest I ever got to an FO in my 11 years in the WG), but in the end discussion was far more productive and an FO was not necessary. 😊

Happy to work on the issues via some other mechanism (like Anders says, wrapping them in a different kind of rule instead - let's re-re-revive @nest!), but I'm absolutely not ok with having different behavior based on the exact selector used.

Do we want to repurpose this thread to discussing how to solve the "naked property nesting inherits some of Nesting's weaknesses" issue, or open a fresh issue?

I think it's more important to establish why these weaknesses are necessary in the first place, and explore ways to get rid of them before we decide to add even more syntax to CSS to do similar but slightly different things (which is an antipattern from a UX/DX perspective).

[FremyCompany]

I think the issue mentioned on the call (and some people didn't really understand) is that:

article, .article {
    color: red; 
    & * { color: green; }
}

maps to

article, .article { color: red; }
:is(article, .article) * { color: green; }

which has a different specificity from

article, .article { color: red }
article *, .article * { color: green }

and may authors (including me) would have expected the latter one, not the first one

but, as Tab mentioned, this rewriting might cause extremely large lists of selectors in the case of deeply nested selectors, so this might end up expensive.

[FremyCompany]

And just to keep adding to the summary, I think the "explode by specificity" that @LeaVerou proposed would work along these lines:

article, .article, .advert {
    color: red;
    @mixin something;
    color: green;
}

can be rewritten

article, .article {
    color: red;
    @mixin something;
    :where(&):is(article), :where(&):is(.article, .advert) { color: green; }
}

Note that, even though it might be undesirable in the general case (no strong opinion on this), it's possible to do this rewriting only in the case of "promoted" declarations where wrapping & {} would result in wrong specificity for the declaration after promotion.

I would personally be fine with something like this being done only for the rare case of out-of-order declarations. But this begs the question whether this should be the default indeed. I think implementors should give it some thought. It might not be as difficult as it looks like.

If we do it for everything, then simply nesting into a & {} block becomes fine again for out-of-order declaration promotion.

[Loirooriol]

The problem is basically the same as in #1027

#a1, .a2, a3 {
& #b1, & .b2, & b3 {
& #c1, & .c2, & c3 {
& #d1, & .d2, & d3 {
& #e1, & .e2, & e3 {
& #f1, & .f2, & f3 {

Very short, but there are 729 possible different ways to match this. If the specificity can vary, then it has a performance impact, e.g. knowing that the element matches .a2 .b2 .c2 .d2 .e2 .f2 is not enough, because maybe it also matches a3 #b1 .c2 d3 .e2 f3 which has a higher specificity. So checking all/several possible combinations is needed.

I still don't see how the specificity concern is related to #8738. And while I can see it might be confusing, it doesn't seem inconsistent nor anything. As I said in #9492 (comment), I don't see the need to change the current specificity.

@FremyCompany Your idea would imply a combinatorial explosion?

[tabatkins]

It may help to explain your reasoning rather than just vetoing things.

Yes, I did explain my reasoning, in an immediately preceding comment, and this topic was discussed in older Nesting discussions already so I wasn't sure of how much I should repeat. I posted my veto as a separate comment, rather than just editting my previous ones, to make sure it was expressed in the email record as well. Let me be more explicit, tho.

As expressed in the call again, by me and Oriol, we cannot solve the general case of making specificity match that of fully-unnested rules, because that entails an exponential explosion of possible specificities.

For example, given:

div, .div, #div {
 div, .div, #div {
  div, .div, #div {
   div, .div, #div { ... }
  }
 }
}

There are already 3^4 = 81 unique specificities that the innermost properties could potentially have, depending on what precisely they matched. Adding another level would triple it again, to 243; adding a fourth selector to each level would similarly roughly triple it to 4^4 = 256.

There's no workaround here. An author writing out a selector list with 256 options can easily see there might be a performance issue with that. An author writing four nested rules, each relatively short, might not be aware of that at all. And it's only a short step away from millions or paths, or more.

In the call, you suggested we could do some intelligent coalescing of specificities at each level; if the author writes .foo, .bar, .baz, ... it doesn't matter how long the list is, every option's specificity is [0, 1, 0]. (@FremyCompany also just suggested this, above.) This doesn't solve the general case, however; at best it can slow down the exponential growth, but not prevent it, and the example I wrote above wouldn't be helped by it at all, since every option has a different specificity anyway. So this is similarly unworkable; it's still easy for authors to exceed the compute budget, accidentally or intentionally.

---

However, while the general case is unsolveable, the specific case of .foo, #bar { @media (...) { color: red; } } wanting to have the same specificity as if it were nested the other way around is solveable.

As I said, I'd object to treating a rule with a lone & differently; this sort of context-sensitivity is confusing for authors and means that seemingly-innocent changes like adding an additional selector to a list can change the meaning of other selectors they didn't touch.

But adding a new construct that explicitly handles this case is fine. I alluded to this above, so let me give the proposal more explicitly:

Add a new @nest rule. It has no prelude, and allows nested properties inside of it. It matches exactly the same elements and/or pseudo-elements as the parent rule, and applies its nested properties to those elements with the same specificity as the parent rule. Use @nest as the wrapping rule for properties after at-rules, or for naked properties in conditional rules (rather than an & {...} rule, as currently specified).

Examples:

div, .foo, #bar::before {
	color: blue;
	@media (...) { color: red; }
	color: green;
}

/* Today, desugars to: */

div, .foo, #bar::before {
	color: blue;
	color: green;
}
@media (...) {
	:is(div, .foo) { color: red; } 
	/* different specificity, and loses the `::before` selector :( */
}

/* With @nest, it'll be treated as (and reflected in the OM as): */

div, .foo, #bar::before {
	color: blue;
	@media (...) { 
		@nest { color: red; } 
	}
	@nest {
		color: green;
	}
}

/* Which desugars to: */
div, .foo, #bar::before {
	color: blue;
}
@media (...) {
	div, .foo, #bar::before { color: red; }
}
div, .foo, #bar::before {
	color: green;
}