-
Notifications
You must be signed in to change notification settings - Fork 378
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Shadow]: return of multiple shadow roots? #780
Comments
Hmm. I can say that Google is no longer interested in supporting multiple shadow roots. :( |
I think I can somewhat safely say that Mozilla isn't either at least for the next five years or so. There's a lot more work to be done on shadow roots and custom elements in making them more robust and an integral part of the web platform. And then in terms of new features modules and perhaps templating are more interesting to us. |
Indeed, again, Apple is not interested in adding back multiple generations of the shadow DOM. I don't think that kind of transparent enhancement never really works because sooner or later, they would start interfering with one another regardless of whether they use a separate shadow tree or not. At the end of the day, if some script is showing a tooltip, then other script which shows overlays, dialog, etc... needs to be aware of it; e.g. to avoid showing another overlay on top of it. |
Fair enough, thanks for the clarification from the main vendor representatives. |
Multiple shadow roots were removed as per #90, because Apple didn't want them and others were happy to defer them to a later version of the spec. Complexity aside, there were plenty of great things about multiple shadow roots, not least the ability to transparently attach multiple behaviours to an element without fear of collisions in styles, ids or other attributes.
Take the
<body>
element, for instance. A 3rd-party library wants to add a positioned tooltip, another wants to add some popups, another some dialogues. Maybe a browser addon wants to decorate parts of the body without interfering with a website. Without multiple shadow roots, none of these parties can act transparently, with 100% certainty that they won't introduce side effects by adding elements and styles to the dom. One of them could create a shadow root, but that prevents the others (or the page owner) from doing the same. If each could own a shadow tree on the body, they could add their own stylesheets or manipulate elements with full confidence in the encapsulation.Is there still vendor interest in returning nested shadow roots in the future?
The text was updated successfully, but these errors were encountered: