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

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](https://drafts.csswg.org/css-cascade/#cascade-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 expllainer) - 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 right isn't about solving 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!

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