[csswg-drafts] [css-cascade-6] Should the scope proximity calculation be impacted by nesting scopes? (#10795)

mirisuzanne has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-cascade-6] Should the scope proximity calculation be impacted by nesting scopes? ==
**Background:**

The [published definition of 'scope proximity'](https://www.w3.org/TR/2023/WD-css-cascade-6-20230321/#weak-scoping-proximity) states that:

> If two declarations both have elements selected by scoped descendant relationships applying [weak scoping proximity](https://www.w3.org/TR/2023/WD-css-cascade-6-20230321/#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](https://www.w3.org/TR/2023/WD-css-cascade-6-20230321/#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](https://drafts.csswg.org/css-cascade-6/#cascade-proximity), the [second paragraph was removed](https://github.com/w3c/csswg-drafts/commit/14969b2734054668d291f0ddba316e2255be1e4c) and [the first paragraph adjusted](https://github.com/w3c/csswg-drafts/commit/180fce46e5fd765b1c7ed6bcf122961cae8486be), so that each scoped selector has _one single scope root_ and a single proximity number.

In [our publishing discussion last week](https://github.com/w3c/csswg-drafts/issues/10370#issuecomment-2302527862), @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:

```css
@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. Is there a situation in which this is helpful for authors?

I'm not opposed, but I'm also not convinced. It would be interesting to hear from authors.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10795 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 28 August 2024 03:25:15 UTC