[css-nesting] [css-cascade-6] Clarify behavior of @scope with nesting

[devongovett]

The CSS nesting spec has the following example:

.parent {
  color: blue;

  @scope (& > .scope) to (& .limit) {
    & .content {
      color: red;
    }
  }
}

which it says is equivalent to:

.parent { color: blue; }
@scope (.parent > .scope) to (.parent > .scope .limit) {
  .parent > .scope .content {
    color: red;
  }
}

However, according to my reading of css-cascade-6, this seems slightly incorrect.

By default, selectors in a scoped style rule are relative selectors, with the scoping root and descendant combinator implied at the start.

Following this, it would seem that showing .parent > .scope in the nested style rule would be incorrect and redundant, since the rule would already have an implicit :scope prefix. Would it be more correct to show this in the example instead:

.parent { color: blue; }
@scope (.parent > .scope) to (.parent > .scope .limit) {
  :scope .content {
    color: red;
  }
}

where :scope is equal to .parent > .scope as defined in the rule's <scope-start>?

Maybe I'm reading it incorrectly. It's sorta confusing that this is split between two different specifications.

[mdubet]

In this case, the selector list of the inner rule has an explicit &, thus it doesn't have the implicit :scope.
(but it ends up being the same selector anyway)

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 (but the subject must still be in scope to match).

[mirisuzanne]

Yeah, I see how that example is potentially confusing, because it removes the explicit & from the 'result' - which is not the same as if that was written directly, and had the implicit & applied. I'm not sure there's an obvious fix besides rewording the example. Marking this as editorial, if someone wants to suggest an edit - or if one of the nesting spec authors wants to pick it up.