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

The use-case mentioned on the call is:

```css
@scope (a) {
  @scope (b) {
    c { color: blue; }
  }

  color: yellow;
}
```

With the DOM:

```html
<a><b><a><c>hello</c></a></b></a>
```

Currently all three proposals above would give the same result, since the proximity of the first step provides a clear winner (`a->c` is fewer steps than `b->c`). If we prioritize _number of scopes_ above proximity, we would reverse the result. But at that point we're just re-creating a more blunt form of specificity, right? We're saying that the number or selectors involved should matter more than their proximity in the dom. Which is _why we opted for proximity-after-specificity_ in the first place. And it seems to me (maybe this is what @5t3ph was getting at) that the real concern here is with scopes not adding specificity.

The reason we would expect `blue` to win, is because we expect specificity.

So @noamr I don't know if you were confused, but I agree with the statement. I don't know that the problem here is how we've defined proximity - but the fact some people might want scopes to _increase specificity_ along the way (which they can do by using `&`). Or, as you suggest, could use layers. Because the confusion isn't about proximity at all, but wanting to override it sometimes.

-- 
GitHub Notification of comment by mirisuzanne
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10795#issuecomment-2433041143 using your GitHub account


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

Received on Wednesday, 23 October 2024 18:08:09 UTC