[css-cascade-6] & matching inside the @scope, and its interaction with :scope

[kizu]

In some way, this is a follow-up to the #9739, but I felt that this is a different case that could be discussed separately.

While testing different ways scopes interact when being nested, and how & and :scope behave inside, I found one place that should either be clarified in the specs, or maybe changed.

I'm talking about two parts in particular.

From 2.5.1. Effects of @scope

The & selector is defined to represent the selector representing the scoping root (the <scope-start> selector), or else :scope if no selector was specified.

From 2.5.3. Scoped Style Rules

Any selector in the <relative-selector-list> that does not start with a combinator but does contain the nesting selector or the :scope selector, is interpreted as a non-relative selector

The short version of my question: Should & represent only the scoping root selector, or both the selector and :scope?

The reasoning behind my question: right now, there is a difference when we use & or &:scope inside a scope.

When we have only &, we, essentially, lose the :scope completely, making it so the & will match any similar node, not necessarily if it is the scoping root node.

Here is a CodePen demonstrating the current behavior: https://codepen.io/kizu/pen/GReRRxQ

So, the way it works now, the & and :scope are different in two ways:

1. :scope has a specificity of a pseudo-class, and & has a specificity of the scoping root selector.
2. The :scope matches the scoping root node, but & matches only the scoping root selector itself.

The current behavior can be potentially useful, but I'm struggling to come up with actual use cases. We can also always add an explicit :scope and write &:scope to get both effects (or &:where(:scope) if we'd want to only have the specificity of the scoping root selector).

However, there is a chance this difference could result in author confusion and mistakes, as it is very easy to assume that the specificity difference is the only difference.

If this behavior is to stay, I think the specs should be more explicit in how they explain these differences.

Otherwise, I think it might be better to change the & to be the same as :scope — representing the scoping root node, but with a different specificity.

[andruud]

Otherwise, I think it might be better to change the & to be the same as :scope — representing the scoping root node, but with a different specificity.

Hmm, are you sure it's not more confusing to deviate from how & behaves in css-nesting?