Background:

The published definition of 'scope proximity' states that:

If two declarations both have elements selected by scoped descendant relationships applying weak scoping proximity, then the declaration with the fewest generational hops between the ancestor/descendant element pair wins.

If multiple such pairs are represented, their weak scoping proximity weights are compared from innermost scoping relationship to outermost scoping relationship (with any missing pairs weighted as infinity).

However, in the Editor's Draft, the second paragraph was removed and the first paragraph adjusted, so that each scoped selector has one single scope root and a single proximity number.

In our publishing discussion last week, @mdubet asked to reconsider this.

How it might work:

In order to find a 'proximity', we need both a 'subject' element and a ':scope' element. Then we count the 'steps' between one and the other.

Nested @scope rules are allowed. Each scope rule's <scope-start> selector is 'scoped' by the parent scope rule. If we want scopes to accumulate with nesting, we have to determine which subjects we are comparing to which roots. Given this example:

@scope (a) {
  @scope (b) { 
    c { /* … */ }
  }
}

I see two options (though I believe they might be functionally the same??). The scope proximity weight for c is one of:

• [c-to-b-distance, c-to-a-distance]
• [c-to-b-distance, b-to-a-distance]

In either case, I believe the proposal is to compare proximities from inner-most to outer-most.

But why?

I think this would be a reasonable approach. At least, it makes some sense to me that things might work this way. But I can't think of an actual use-case where I would rely on this behavior. I'm not opposed, but I'm also not sure how useful or complex it is.