Hacker News Reader

Comment by throwaway894345 | Hacker News Reader

It exists to help you define components without running into naming conflicts. For example, if I want to make a "my-button" component that has a <button class="button"> and some CSS that targets `.button { ... }`, I won't end up styling a bunch of other things that have `class=button`. Pretty sure it also protects against other things doing `document.getElementById("button")` and getting the element whose ID is `button` from your component instead of whatever the caller was expecting. Effectively, shadow DOM provides encapsulation.

View on HN

That's true, but they didn't ratify yet a standard on how to handle web components naming collision, so if you create `my-button` and another developer register `my-button`... Or if you want to use two different version of your own `my-button`...

This is the proposal for scoped elements: https://github.com/WICG/webcomponents/blob/gh-pages/proposal...

Yeah well, good old XML already had this handled through XML namespaces.

What happens when your namespaces collide? (:

The namespaces are URLs, so DNS ensures the domain names are unique globally, the owner of each domain name ensures the paths are unique for that domain, and the author of the XML document ensures the namespace aliases are unique for the specific namespaces used in that specific document.

Is it accurate to mentally model this feature as browser mounting/applying CSS not to the document, but to the arbitrary DOM element in it?

I’m probably the wrong person to ask, but my mental model is that it scopes/isolated the CSS inside the component so it doesn’t affect elements elsewhere in the document but it also prevents CSS elsewhere in the document from affecting the elements in the component.

My outstanding question here is: how do people reuse components across sites with different themes? Do they have to pass styles across the shadow boundary via JS? Or do they just give up on cross-project reuse or theming?

Reply on news.ycombinator.com