That's quite a good reason. It'll be useful for embedding content in pages; if you have complete control over the page then that isn't especially helpful, but if you don't (many teams contributing to a site, accepting user defined content in to a page, enabling an admin to define page styles without breaking important elements, etc) then it's very handy.
My inner pessimist does wonder if Google are driving this because it'll somehow make it harder to block adverts, but for now it looks quite useful in for the obvious use cases.
The shadow DOM is critical to make sure that my extension's styles don't overwrite the page's styles and vice versa. And unlike iframes, it grants the ability to use js state management that extends beyond the shadow DOM root element. So, you can inject multiple shadow DOMs capable of "talking" to each other.
`<style scoped>`
However, it was abandoned partly because it "adds a lot of complexity to how the scoped style system works for Shadow DOM".
https://chromestatus.com/feature/5374137958662144
https://groups.google.com/a/chromium.org/g/blink-dev/c/R1x18...
There were other reasons at the time as well, as mentioned in the linked email: the feature wasn't owned, wasn't shipping in any browser, and was making it difficult to improve the Shadow DOM styling system which was shipped already.
That was also a long time ago, and I think browsers and standards groups have learned a lot about designing features to be backwards compatible and how to avoid certain implementation complexities.
Component-scoped styles is a very handy feature. It could be achieved just by leveraging selector specificity, but that's rather complex and a lot of people hate CSS so less cognitive overhead is better.
This is why I love Vue. It's basically the nightly version of HTML/CSS/JS. The syntax from this article is already familiar from Vue. It extends web standards, rather than replacing them, IMO.
I've seen it work on Chrome, Firefox and Edge. But at the time I discovered it, Chrome had already scheduled it for exclusion.
It was shipping in Firefox when I removed it from Chrome. It was moved behind a flag in Firefox shortly after and then support was removed.
You probably won't write the raw code yourself.
These web component APIs are generally low level and with few conveniences. The idea is that your Framework of Choice would do the raw code and you dear application developer would get it in some handy "cooked" way which matched your framework. (For example, maybe outputting isolated components could be simple boolean in your build configuration.)
Too many people think that the raw web component specs are meant to compete with frameworks like React etc. But that is huge misunderstanding. They're low level APIs which frameworks can build on.
Intuitively, I'm sure the whole Shadow DOM thing is way more powerful than that, but this is their 2nd-sentence headline example of what Shadow DOM "does."
Surely, there are reasons for all this complexity beyond stylesheet compartmentalization? Would I ever personally want to write the "raw" code to work with the Shadow DOM (not from the looks of it) unless I were a developer of some low-level framework that needs to be optimized to not manipulate the real DOM?