[csswg-drafts] [css-cascade-6] The specificity of a scope rule (#8500)

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

== [css-cascade-6] The specificity of a scope rule ==
The `@scope` rule prelude includes two selector lists - one for determining scope 'root' elements, and the other for setting 'scope boundaries' that prune branches from a scope tree:

```css
@scope (.media-object) to (.nested-content) { 
  img { … }
}
```

The primary impact that people want from scope is the 'scoping' behaviors:

- supplying lower-boundaries
- applying scope proximity to the cascade

But there's currently a side-effect built-in, which authors seem to be split on: **should the scope prelude selectors have any impact on the specificity of scoped selectors?** The arguments for and against are roughly:

1. Yes, apply scope root specificity (`[0, 1, 1]` for example above). Scope has some overlap with nesting, so the two should have similar behavior. It makes sense that selectors used to narrow the targeting of sub-selectors would consistently apply their specificity to the final match.
2. No, don't apply scope specificity (`[0, 0, 1]` for example above). There are currently no at-rules with specificity, and it would be a side-effect of 'scope' - rather than an essential part of the feature. The cascade behavior we want from scope is already represented by proximity. In order to clearly distinguish scope from nesting (and to keep specificity under control) we should avoid adding that side-effect.

I did [a small poll recently](https://front-end.social/@mia/109910190042561169), and the ~50/50 results match my less formal conversations. Neither was consistently in the lead, but it was swapping back and forth throughout the duration of the poll. 

**There is not a 'right' answer here in terms of the scope feature doing what it is meant to do.** In either case, authors have other ways to manage the specificity. With option 1, they can use `:where()` inside scope rules to remove specificity. With option 2, they can add specificity to the nested selectors in various ways (I expect using `&` would directly apply the root selector specificity).

The current spec uses option 1. I'd lean slightly towards option 2 at this point, convinced by the argument that it's an unnecessary side-effect of the feature. But I believe they are both workable solutions.

(Adding agenda+ in hopes we can cover this during the scope breakout session)

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


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

Received on Monday, 27 February 2023 17:33:57 UTC