Hacker News Reader

Comment by akersten | Hacker News Reader

With the disclaimer that I might be getting old, and I have done absolutely no research on my own about this whole shadow DOM thing: why would you go through all this trouble to "[provide] a way to scope CSS styles to a specific DOM subtree and isolate that subtree from the rest of the document."

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?

View on HN

Surely, there are reasons for all this complexity beyond stylesheet compartmentalization?

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.

I'm developing a browser extension that injects a little popup window onto webpages using content scripts.

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.

Chrome was at one point developing a `scoped` attribute on the `<style>` element for scoping stylesheets that would not require WebComponents.

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

It's alive and well in Vue.js single-file components (SFC). Once built, it is implemented by using data attributes in the CSS selectors.

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.

> wasn't shipping in any browser

I've seen it work on Chrome, Firefox and Edge. But at the time I discovered it, Chrome had already scheduled it for exclusion.

I'm pretty sure it was never implemented in Edge and I know it was never shipped in Chrome, but you're right I misspoke above.

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.

https://caniuse.com/style-scoped

Stylesheet encapsulation is a godsend for my particular use case. I work on a web chat product that's placed on various sites - CSS scoping solves 90% of our deployment issues.

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

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.

I agree: CSS selectors are already supposed to provide extreme flexibility in assigning CSS props, and give you means to organize scopes etc to implement Shadow DOM compartment policies, among all the other things.

In theory, yes, but in practice it's a different story. Early on in a project's life, avoiding these pitfalls is easy. But as a project grows both in team and codebase size, those quick CSS hacks to get some functionality out the door accumulate. After some time, you will begin to run into issues where some components in the tree aren't rendering the way you expect because some other component(s) are applying styles using a selector that may have worked at the time, but is now too broad. Even if your app is 100% CSS in JS, though easier to avoid, you may run into these issues. I'm all for this feature.

Reply on news.ycombinator.com