[css-cascade] Allow making a scope's upper bound really inclusive (evaluate nested selectors against it)

[benface]

MDN says:

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 evaluate the selectors of all nested rules against the root element. Here's what I mean, with an imagined new including keyword:

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

<button type="button" class="my-design-system bg-primary">
  This button has the `--ds-bg-primary` background color!
</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:

@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), so we add a class (my-design-system) to all our components' root elements and wrap all of our library's CSS with @scope (.my-design-system)... 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. 🤞

[romainmenke]

This is more about how relative selectors work.

By default, selectors in a scoped style rule are relative selectors, with the scoping root and descendant combinator implied at the start.

https://drafts.csswg.org/css-cascade-6/#scoped-rules

---

Something like @scope including (.my-design-system) would still need a definition of a scoping root that makes sense for relative selectors.

This scoping root would still have the implicit behavior of relative selectors:

@scope including (.my-design-system) {
  :special-scoping-root .bg-primary {}
}

This wouldn't be different from:

@scope (:has(> .my-design-system)) {
  .bg-primary {}
}

Which doesn't really work as you want:

<div>
  <div class="my-design-system bg-primary">
  </div>
  
  <div class="bg-primary">
    unrelated, but also selected
  </div>
</div>

---

Some new selector would slot in more nicely with existing features:

@scope (.my-design-system) {
  :in-scope.bg-primary { background-color: var(--ds-bg-primary); }
}

Where :in-scope would make the selector non-relative.
It would be a less gnarly alias of :is(:scope, *).bg-primary

[benface]

@romainmenke – Interesting, thank you so much for the clear explanation! I was hoping for a solution that works with the upcoming @import scope() syntax, in the sense that any existing stylesheet can be scoped, which means the scoped rules shouldn't have to know about :scope (not to mention that I don't think :in-scope is really an improvement over :is(:scope, *)). I would specifically want to use this technique with Tailwind CSS-generated utilities, and I don't see them adding support for such a niche use case.

[romainmenke]

This scoping root would still have the implicit behavior of relative selectors:

@scope including (.my-design-system) {
 :special-scoping-root .bg-primary {}
}

This wouldn't be different from:

@scope (:has(> .my-design-system)) {
 .bg-primary {}
}

Thinking about this more, the definition of the @scope root maybe doesn't need to align with the scoping root for the relative selectors itself?

So @scope including (.my-design-system) could create a scope that is exactly the same as @scope (.my-design-system) but the scoping root for selectors would be :has(> :scope).

The scope would still prevent elements from outside the scope from being matched.

Still weird that the scope root for @scope isn't the same as the scoping root for the relative selectors 🤷

---

I do think the use case is valid.
Not only for utility classes by anywhere you want to scope an entire stylesheet to a sub section of the element tree.

The only way to do that now is to add wrapper elements around each section, as you said.

But that assumes control over the html.
Maybe there are 3rd party elements with slots for even more 3rd party elements.

Unsure how this is best solved.