Shadow dom is awesome, but we use polymer to build quite a complex and large web app. It might not be optimal to create a shadow root for every element in this application, especially not for non-visual elements and logistical elements that are just there for code splitting and templating the top level parts of the application.
I am concerned about the performance consequences of creating a shadowroot for each element, especially on browser where this needs to be polyfilled. Also shadowroots complicate writing e2e tests with tools such as selenium, as you're not longer able to easily select interactive elements on the page.
I've been digging around and from what I can tell the recommended to not use shadow dom for an element, is to override the _attachDom method as such:
_attachDom(dom) {
this.appendChild(dom);
}
This works, a shadowroot is not created and the dom is attached to the light dom. However when the shady dom polyfill is enabled, styles are still hoisted to the main document. Including a style tag within an element without shadow root has its quirks, but for singleton elements in an application I think it's still useful to have.
What is the recommend way to deal with this? It seems to me like it would be much clearer for developers if there is a static configuration you can set on a polymer element to enable or disable shadow dom so that different parts of the system can hook into this.
@LarsDenBakker Does https://github.com/Polymer/polymer/issues/4824#issuecomment-350884005 clarify more? It includes a workaround that should work as well.
Yes that clarifies the issue. Thank you. I will look into the workaround, but I think it still useful for the Polymer library to acknowledge and account for use cases of elements without shadow dom.
@LarsDenBakker @TimvdLippe
Yeah, i would say it's a must have feature, to indicate how the component will be rendered, using Shady/Shadow dom. Ideally is to have it as a property, defined per component. If not defined, we can enable Shadow dom by default.
I face the same issue, when the root component composed by iterable children of iterable children.
Why do we need to enforce Shadow dom creation on them? Why the Shadow dom scoped root component is not enough?
Added @azakus as it seems he rules here the things..
+1 for clear API for this (not quirks/workarounds),
it completely makes sense when we create application (not reusable) components
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Most helpful comment
+1 for clear API for this (not quirks/workarounds),
it completely makes sense when we create application (not reusable) components