Scope vs Shadow DOM
When CSS grid first arrived, there were a lot of people saying, “Why do we need this? We already have flexbox!” I’m getting very much the same vibe now with @scope, especially from enthusiasts of web components and shadow DOM.
But here’s the thing: CSS @scope and shadow DOM are not competing standards. They’re complementary. They meet different needs entirely — but with enough healthy overlap in functionality so there isn’t a gap.
So should we make shadow DOM more ergonomic? Yes please! I’m all for continuing to improve the specification here. By promoting @scope, I’m not belittling shadow DOM. Please don’t take this following statement as a criticism:
Shadow DOM does not provide what @scope does¶
Language is hard, especially when it comes to the terms we use in the industry to convey various ideas. The term component, for instance, can mean multiple different things to different developers.
Similarly, something different comes to mind for all of us when we hear about the concept of style scoping. This is only natural, because we all work in different corners of the industry. We’ve each had to tackle problems and use cases that others haven’t.
It’s so easy to hear that @scope is coming to CSS and think, “wait, don’t we already have scoping in the shadow DOM?” — because we do have scoping in the shadow DOM. But it’s a very different definition of scoping!
Shadow DOM and web components are perfect for some use cases. If you need to encapsulate something so others can put it on their sites, this is exactly what you need. Red Hat does this: the navigation bar at the top of the page on many Red Hat sites is a web component. This works well because:
- these sites are all branded the same, and
- they each need the same user experience for navigation.
Something like an embedded social media post is probably another perfect use-case.
This is not what @scope is for.
Shadow DOM is strongly isolated from the rest of the page. Essentially, shadow DOM throws away the entire CSS cascade. It cuts a hole out of the page, and allows you to put something else in that hole.
But this is not everybody’s use case. If you are working on a single web application, with unique branding and a consistent user experience, the last thing you want is to isolate all the parts of the page from the cascade. You want everything to look and feel the same! You want the cascade to apply, but with the ability to explicitly control how it applies. Components need to be able to override parts of the cascade — but not be isolated from it entirely.
@scope is about embracing the cascade, and controlling it. In many ways, this is the exact opposite of what shadow DOM does.
Yes, shadow DOM should continue to grow and be improved, but at a fundamental level, it does not address the same problem @scope does. Yes, both scope styles, but they are two radically different definitions of scope. 1
The greatest shortcoming in our industry¶
I have never personally needed shadow DOM. Every time I dig in to assess it, I come away frustrated.
At first, I thought this was a failing of the spec — how could they be so out of touch with the real needs of developers? But since then I’ve realized that’s not it at all.
Instead, I have slowly realized that the needs across our industry vary wildly. Some developers love shadow DOM, because it does exactly what they need. But when they look at @scope, they feel the same way I do when I look at shadow DOM — it’s not at all the right tool for their job.
This is something our industry is terrible at: we are really bad at understanding and appreciating the varying needs of other developers who work on different problems than us. Why would someone want to colocate their CSS inside their JavaScript files? Why would someone be so vehement about avoiding a JavaScript framework? Why would someone want to entirely encapsulate their web components from the light DOM? And why would someone want this @scope thing when we already have shadow DOM?
We each solve different problems and often have wildly different needs from our tech tools. That’s okay. That’s healthy.
For me, and my problem space, shadow DOM is a backwards paradigm to the one I need. I long for @scope.
Maybe you don’t. And that’s fine.
But please don’t try to shoot down the one feature that’s been desperately missing from CSS because you don’t have a personal need for it.