Early design review of light-DOM CSS Scope proposal

[mirisuzanne]

HIQaH! QaH! TAG!

I'm requesting early TAG review of my proposal for light-DOM CSS Scope.

Previous scope proposals have attempted to address highly-isolated use-cases along side the more light-touch issues of namespacing and selector-proximity. Those attempts were largely abandoned in favor of Shadow-DOM solutions -- which strongly prioritize strong isolation. In the meantime, third-party tools (eg CSS Modules) and conventions (eg BEM) are more often used by authors to provide low-isolation scoping for light-DOM components. I'm proposing a native CSS approach to those use-cases.

• Explainer: https://github.com/oddbird/css-sandbox/blob/main/src/scope/explainer.md
• Security and Privacy self-review: This proposal does not expose anything new, and has no impact on security or privacy
• Primary contacts (and their relationship to the specification):
  • Miriam Suzanne, @mirisuzanne, Invited Expert, author
  • Mason Freed, @mfreed7, Google, contributor
  • Yu Han, @yuzhe-han, Google, contributor
  • Rune Lillesveen, @lilles, Google, contributor
  • Rossen Atanassof, @atanassov, Microsoft, co-chair
  • Alan Stearns @astearns, Adobe, co-chair
• Organization/project driving the design: CSSWG
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status):
  • Earlier discussion of scope on CSSWG: [css-scoping] Please bring back scoped styles w3c/csswg-drafts#3547

Further details:

• I have reviewed the TAG's API Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): CSSWG
• The group where standardization of this work is intended to be done ("unknown" if not known): CSSWG
• Existing major pieces of multi-stakeholder review or discussion of this design: CSSWG Issue
• Major unresolved issues with or opposition to this design: No known opposition
• This work is being funded by: Google

We'd prefer the TAG provide feedback as 💬 leave review feedback as a comment in this issue and @-notify @mirisuzanne and @lilles

[kenchris]

Hi there,

Here are some of my initial thoughts.

I would really like to know how this ties into other CSS scoping methods like shadow DOM and the proposed WICG/webcomponents#909 And would especially like to hear the feedback from @rniwa and @hober

I think that having multiple CSS scoping methods that aren't build on the same principles or underlying primitives is problematic, and we should attempt to avoid that.

There are real problems with shadow DOM scoping today, but solving those outside of shadow DOM would not be ideal. For instance, I have heard the need for scoped light DOM styling, ie. a more powerful ::slotted(), which seems related to this.

[mirisuzanne]

Thanks for the quick feedback @kenchris!

I agree that it's confusing to have both models use the language of "scope", but I don't think it means we can conflate them. While there are some similarities, these are two distinct problems – both with valid use-cases, but requiring distinct solutions. I've been happy to see that recent Cascade drafts refer to "encapsulation context" rather than "scope" for Shadow-DOM isolation. I'm also open to changing any of the language in this proposal - though I think this is the more common use of "scope" that authors are familiar with in the existing tools.

• Shadow DOM is designed around a model where elements are explicitly "closed off" in the DOM, before any styles are applied. There is a distinct boundary between the "host" page and the nested "component" which is intrinsic to the component semantics in the DOM itself. Each isolated component has a single isolated scope. From there, it can be useful to "open up" isolated components in a controlled way, and allow some contextual styling. We should absolutely make this model more flexible, and improve on it. I like the existing proposals (I mention a proposal by Yu Han in the explainer) - and I think they would be good to pursue as well. But I believe the use-case I'm addressing is fundamentally different, and does not actually overlap in more than name.
• The more common model is entirely presentational, and belongs purely in style sheets. This isn't about isolating clearly-defined components, but making small improvements to how we target selectors. In this use-case there is no clear boundary between a host and isolated components. Every page is entirely composed of nested & overlapping/composable "objects" – reusable styling patterns that don't always align with distinct DOM elements. Very different components can share a similar stylistic pattern. The required "scopes" are fluid and overlapping, not directly tied to distinct DOM elements, so there are no clear intrinsic boundaries to draw before applying styles. For this use-case, authors want the ability to target selectors in some more explicit ways – with awareness of ancestor-proximity & lower bounds – but that's all. DOM isolation is not a good solution to this entirely presentational problem, even with added flexibility.

My proposal here is that getting shadow-DOM shouldn't solve both use-cases, but should instead free us up to solve the remaining presentation/selector-targeting use-case as a distinct problem-set.

I hope that's a helpful clarification. Thanks again for your thoughts!

[LeaVerou]

I'm very happy to see a proposal that aims to address the problems that cause patterns like BEM or CSS Modules to proliferate.
Also, nice, thorough explainer. 💯

So, to decouple the different parts of this:

• Namespacing is addressed via essentially nesting + proximity prioritization through a new @scope rule
• Subtrees can optionally be excluded from matching via lower boundaries. This seems useful beyond @scope, so I wonder if it would be better expressed as a selector extension.

Some lower level comments below.

I think this should work inside and outside of the shadow DOM without any special concern for shadow boundaries.

This is a bit ambiguous. I can see two possible meanings:

1. @scope should match on the whole tree ignoring shadow boundaries.
2. It should be possible to use @scope both in CSS that is applied to light DOM, as well as CSS that is applied to Shadow DOM.

If you meant 2, that seems pretty uncontroversial. But in case you meant 1:

I think this would break author assumptions about shadow DOM. Also, it was decided early on that we don't want explicit access to styling shadow DOM structure that has not been explicitly exported. Furthermore, my understanding of implementations is that this kind of selector matching across Shadow DOM boundaries would be very difficult to implement.

Given a syntax of @scope (<selector>), are we placing any restrictions on the <selector>?

It is unclear whether the parentheses are optional or mandatory. In the examples that follow the part I quoted, there are no parentheses. Is that a typo or does it intentionally demonstrate that no parentheses are required in certain cases? Parentheses should definitely be required to disambiguate complex selectors, otherwise you don't know if @scope foo to bar is scoping foo until bar or just scoping under selector foo to bar (to could be a type selector targeting <to> elements).

Getting even more complex, is there reason to allow selector lists -- defining multiple roots for a single scope block?

I definitely see use cases for selector lists as lower boundaries, e.g. blocks with multiple different areas to exclude.

Can scoped selectors reference external context?

It is definitely useful to be able to vary a component's style based on its context. However, simply allowing a part of the selector to match outside the scope could lead to unintentional effects, when the author has not anticipated this. Consider this:

<div class="b">
	<div class="a">
		<div class="c"></div>
	</div>
</div>

@scope (.b) {
	.a .c { /* matches! */ }
}

Now consider this HTML, with the same CSS:

<div class="a">
	<div class="b">
		<div class="c"></div>
	</div>
</div>

The rule still matches, but the author may have not intended this, which breaks the isolation.
To enable the use cases without unintended leaking I would suggest an explicit opt-in of some sort. Perhaps selectors containing :scope?

For normal declarations the inner scope's declarations override, but for ''!important'' rules outer scope's override.

Could you elaborate on this? I don't understand it as written.

Another idea that I considered was to combine the specificity of the scope selector to the specificity of nested rule-blocks:

Until this point, I was under the impression that part of the reason for having an at-rule instead of a "donut" selector was the different cascade mechanism. If it just resolves to the same specificity as nesting, then it could have scope leaks. Consider this:

#main a { color: red }

@scope (.my-component) {
	a { color: purple; }
}

<main id="main">
	<div class="my-component">
		<a>This is red?!</a>
	</div>
</main>

---

It may also be interesting to explore what a JS API for fetching "donut scope" elements could look like. I've often needed this, and ended up querying and filtering using element.matches(), which is rather expensive.
On the other hand, if the lower boundary is expressed via a selector, and @scope merely enforces the different scoping, regular qSA would suffice.

---

@kenchris

I think that having multiple CSS scoping methods that aren't build on the same principles or underlying primitives is problematic, and we should attempt to avoid that.

This gives me pause as well. It would be great if these issues can be solved with existing primitives. Though if there are widespread problems the existing primitives cannot reasonably address, solving the problems is more important than keeping the set of primitives constant.

There are real problems with shadow DOM scoping today, but solving those outside of shadow DOM would not be ideal. For instance, I have heard the need for scoped light DOM styling, ie. a more powerful ::slotted(), which seems related to this.

My understanding is that this solves different problems than Shadow DOM. There are many use cases for partial style encapsulation where that is the only kind of encapsulation needed, and Shadow DOM would be too heavyweight a solution. Also, this being entirely a CSS side solution means it can address use cases where existing HTML is being styled.