Re: [csswg-drafts] [css-scoping] Proposal for light-dom scoping/namespacing with re-designed `@scope` rule (#5809)

My [scope slides](https://slides.oddbird.net/csswg/f2f2102/#slide-26) are also [archived as a PDF](https://lists.w3.org/Archives/Public/www-archive/2021Feb/att-0002/Container_Queries_Proposal_-_vF2F_2021-02-09.pdf) (along with the container-query proposal), for anyone interested. Scope proposal begins at slide 26. 

I expected my proposal to make scope proximity _less powerful_ than selector specificity might be surprising compared to previous proposals. But I didn't come to that proposal lightly – it's based on a lot of conversations, and research of the existing tools. In an [informal Twitter poll](https://twitter.com/mirisuzanne/status/1351247559738621952): 


> What color would you expect to see on a paragraph that is matched by both these CSS rules?
> 
> ```css
> @​scope (aside) {
>   p { color: green; }
> }
> 
> aside#sidebar p { color: red; }
> ```

75% of the responses expected specificity to override scope (paragraph text is red). And that makes sense to me for several reasons:

- In current tooling, scope proximity doesn't exist (there's no way to express it in the CSS output). Instead the intent of proximity is achieved only through lower-boundaries. If you don't want styles to leak in from an outer scope, you add lower boundaries to that outer scope.
- In this proposal authors can define an outer scope, and _decide_ if it should flow into nested scopes, or have boundaries applied. Component authors could write strongly contained styles with lower boundaries, and also achieve something like the [Vue "deep" selectors](https://vue-loader.vuejs.org/guide/scoped-css.html#deep-selectors) by having a second scope rule without lower bounds. Rather than making the internal scope powerful so that "no styles get in" we give the external scope boundaries so that "no styles get out".
- If scope proximity overrides specificity, it becomes nearly impossible for authors to penetrate that boundary. The entire goal of this proposal as an alternative to shadow-DOM is that we make the boundaries more flexible, and author-controlled.
- The use-cases I saw where proximity is essential (eg nested light/dark modes) also tended to have the equal specificity, because the goal is to apply variations of the same styles. In that case, we can _fall back_ on proximity without needing it to be powerful. 

-- 
GitHub Notification of comment by mirisuzanne
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5809#issuecomment-795931983 using your GitHub account


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

Received on Wednesday, 10 March 2021 19:11:38 UTC