Re: [w3ctag/design-reviews] Early design review of light-DOM CSS Scope proposal (#593)

Thank you all for the thoughtful notes! I'll work on some clarifications and updates to the proposal based on your feedback. In the meantime, here are some brief answers to the questions you raised:

---

> there's an implicit `:scope` at the beginning of selectors which don't contain an explicit `:scope`. Is that the case?

@hober That's right. I'll add some clarity around it. 

But I'm also a bit wary of using `:scope` here, because it seems to have two conflicting meanings – to either select _the root of the current scope_, or _every element that is a scope root_. I've also had some conversations with @tabatkins about using aspects of the [nesting syntax](https://drafts.csswg.org/css-nesting/) here, like the `&` nesting-selector. I think the meaning of `&` is more clear for this. I'll add a section about that approach to the proposal.

----

@LeaVerou a few of the quick clarifications/answers:

> I wonder if it would be better expressed as a selector extension.

I've done some work on this, but struggled to find a selector approach that makes sense to me. I'll try and document my thoughts on that a bit more, but if you have ideas, I'm interested.

>     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.

Yes, this is what I meant. I agree that scope should respect existing shadow-boundary rules.

> It is unclear whether the parentheses are optional or mandatory.

Yes, this was a typo. I agree that parentheses need to be mandatory.

> I definitely see use cases for selector lists as lower boundaries

I agree for lower boundaries. The question in my mind is if we also need (or should support) selector-lists for the _scope root_.

> Simply allowing a part of the selector to match outside the scope could lead to unintentional effects, when the author has not anticipated this.

That makes sense, thanks. I've updated the explainer to require `:scope` when matching contextual selectors.

> > 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.

That's a quote from the 2014 scope proposal, in which scopes act much like origins – with the order of priority determined by proximity (inner/outer), but that order is reversed for important styles. For example:

```css
@scope (.outer) {
  p {
    font-style: normal;
    color: green !important;
}

@scope (.inner) {
  p {
    font-style: italic;
    color: red !important;
}
```

```html
<div class="outer">
  <div class="inner">
    <p>
       This paragraph would be
       italic (inner-scope has priority for normal declarations), and
       green (outer-scope has priority for important declarations)
  </div>
</div>
```

Shadow-DOM has similar [importance-affected cascade rules](https://drafts.csswg.org/css-cascade-5/#cascade-context), but in the reverse order.

> It may also be interesting to explore what a JS API for fetching "donut scope" elements could look like.

Good question, I'll look into this more - depending where we land on selector-syntax…

----

The biggest question is about where scope belongs in the cascade. I recognize that my approach is a major departure from previous W3C approaches (including both the 2014 `@scope` and shadow-DOM "encapsulation"), and allows global overrides to easily flow through components, and interact with scoped style. That's intentional, and a big part of what makes this stand apart from existing Shadow-DOM encapsulation. 

The primary use-case that I'm trying to address is one in which component-styles are "locked-in" to avoid cross-contamination, but global styles are used to "tie it all together" with consistent patterns like typography and branding. The desired behavior is to prevent scoped styles from leaking out, _without_ getting in the way of global patterns that _should_ flow through easily. If we give scope proximity more weight than specificity, authors are left with very few tools to manage that relationship. By putting proximity _below_ specificity, authors can manage it in several ways:

- Adjust specificity to reflect desired priority, with matching specificity to trigger _proximity_ results.
- Add lower boundaries to avoid overlap of styles

This _leak-in-but-not-out_ approach also matches the existing JS tools & CSS naming conventions that authors already use. Those tools add lower-boundaries, and a single attribute-selector of increased specificity – very easy to override from the global scope. I think this low-weight approach to scope is also backed up by… 

- much of the [long-running conversation on CSSWG](https://github.com/w3c/csswg-drafts/issues/3547) 
- a [quick informal survey on Twitter](https://twitter.com/mirisuzanne/status/1351247559738621952)
- Nicole Sullivan's [explainer from a couple years ago](https://docs.google.com/presentation/d/1Ki-IUCEWU-mNlS-019QVV9I9JsytvafQJHTxpBNfYvI/edit?usp=sharing)

Anecdotally, I hear many CSS beginners surprised that the fallback for specificity is source-order rather than proximity. This proposal would allow authors to opt-into that expected proximity-over-source-order fallback behavior.

Meanwhile, Shadow-DOM already provides the alternative – where "encapsulation context" is weighted higher than specificity, and prevents style leaks in both directions. I think that can be expanded to make it more declarative and even [available in the light DOM](https://docs.google.com/document/d/1hhjmuQE6BTTnAyKP3spDr8sU6lpXArh8LDfihZh78hw/edit?usp=sharinghttps://docs.google.com/document/d/1hhjmuQE6BTTnAyKP3spDr8sU6lpXArh8LDfihZh78hw/edit?usp=sharing), and this proposal would continue to be distinct, and cover a significantly different set of use-cases.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/593#issuecomment-768529617