[css-nesting] wording && "silly", but useful

[tobymackenzie]

Not sure if this is the place to bring this up, but: In the CSS Nesting spec example 5, there is an example showing a nested &&, describing it as "Again, silly, but can even be doubled up." The unnested equivalent of that example is:

.foo { color: blue; }
.foo.foo { padding: 2ch; }

It seems less silly when considering that the .foo.foo has double the specificity (0-2-0) of the .foo selector (0-1-0). That is a somewhat common technique of increasing specificity without changing anything of the "query" of the selector. Being able to chain the & in a nested selector makes it less verbose and easier to manage this technique, and it might be worth noting this to make it more apparent, or at least dropping the "silly" bit.

[kizu]

While this way of handling specificity is very useful ATM, I'm not sure it should be promoted in any way in the specs. Two reasons:

1. Right now, I would always suggest using a [class] to bump the specificity of a selector (which usually has a class). This guarantees that changes to the selector won't break the &&, and if the preprocessors are involved, can result in a more compact CSS if there are long classNames.

2. Either method of adjusting specificity should go away with time, when we would be comfortable with using @layer in our styles and would rely on it more, as using layers is the way to control how things should override each other.

[tobymackenzie]

Interesting. Some comments:

The parent selector & uses :is(), so complicating the selector shouldn't break the && unless there is a pseudo-element involved. As such this technique can be used even for element selectors, which wasn't previously possible with CSS.

SASS at the least doesn't support && and it sounds like in the future they will move to be compatible with the spec, which would imply :is().

I'm not too familiar with layers and they look interesting. But it appears they cannot be used to override any styles outside of a layer, eg from MDN: "…any styles declared outside of a layer will override styles declared in a layer, regardless of specificity". One of the primary use cases I've had for this technique is to override specificity set in other people's code, which I can't touch. If I can @import them, layers would help. Otherwise, it doesn't seem so.

[tabatkins]

Yup, specificity hacks can be useful, but aren't recommended in the future. @layer is the intended way to handle these sorts of collisions in the futurel

[tobymackenzie]

Reasonable. I see that there is an issue for supporting that referenced from the spec, but it is marked as closed. Is something still planned for supporting this?