[csswg-drafts] [css-cascade] Allow making a scope's upper bound really inclusive (check nested selectors against it) (#13391)

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

== [css-cascade] Allow making a scope's upper bound really inclusive (check nested selectors against it) ==
[MDN says:](https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/At-rules/@scope#description)

> **The scope's upper bound is inclusive and its lower bound is exclusive.** To change this behavior, you can combine either selector with a universal child selector. For example, `@scope (scope root) to (scope limit > *)` would make both bounds inclusive, `@scope (scope root > *) to (scope limit)` would make both bounds exclusive, while `@scope (scope root > *) to (scope limit > *)` would give an exclusive upper bound and an inclusive lower bound.

(emphasis mine)

I understand that "the scope's upper bound is inclusive" means that it is _possible_ to style the scope's upper bound within the scope (i.e. with `:scope` or with `&`), but there are cases where I wish we didn't have to be explicit about it and just automatically check the selectors of all nested rules against the upper bound element. Here's what I mean, with an imagined new `include-root` keyword:

```css
@scope include-root (.my-design-system) {
  .bg-primary { background-color: var(--ds-bg-primary); }
  /* other utility classes... */
}
```

```html
<button type="button" class="my-design-system bg-primary">
  This button has the `--ds-bg-primary` background color even though the `bg-primary` class is on the scope root
</button>
```

Imagine we have hundreds or even thousands of such utility classes; this would prevent having to write their selector twice every time just in case one is used on the root:

```css
@scope (.my-design-system) {
  .bg-primary, &.bg-primary { /* ... */ }
  .bg-secondary, &.bg-secondary { /* ... */ }
  /* etc. */
}
```

And why would we want to do that? Imagine we have a component library that uses these utility classes internally, but we don't want them to clash with the author/consumer's own CSS which we don't control (we'd probably also need [some technique to isolate our scope from the rest of the page's styles](https://github.com/w3c/csswg-drafts/issues/11002#issuecomment-3795639646)), so we add a class (`my-design-system`) to all our components' root elements... but then sometimes we need to use a utility class on the root element of the component, not just inside it (whether it's just to get a flatter DOM structure, or because the utility affects the layout in a way that doesn't work if it's nested).

Hopefully this proposal resonates with others. 🤞

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


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

Received on Saturday, 24 January 2026 22:58:38 UTC