3 ms·

I'm on the Polymer team. Shady DOM is probably the biggest beef that we have with the project, but it was a very necessary tradeoff given that the Shadow DOM po

I'm on the Polymer team. Shady DOM is probably the biggest beef that we have with the project, but it was a very necessary tradeoff given that the Shadow DOM polyfill was just too slow. Polymer can seamlessly switch between Shadow DOM and Shady DOM (though your own elements needs to be tested under both). You can still use the Shadow DOM polyfill is compatibility is a higher concern than raw performance. Safari and Chrome will have native Shadow DOM v1 implementations by the end of the year, and quite possibly Firefox. If we have enough resources, we may decided to make an IE/Edge specific Shadow DOM polyfill that'll be much faster because it'll path DOM prototypes rather than wrap DOM nodes. Wrapping is necessary because Safari doesn't properly let you patch Node prototypes. If this happens, we'll have fast and compatible DOM APIs.

pfooti 11y ago
Yes, I'm definitely looking forward to the Real Shadow DOM being browser-supported. I was unable to use the full webcomponents polyfill in my own application, as it introduced gamebreakers with contenteditable-based rich text editors [0]. Putting polymer anywhere on my page meant my rich text editor (quilljs fwiw) broke on non-chrome browsers, even through I wasn't doing anything polymeresque with the editor. It was just the polyfill interacting poorly with the browser's range implementation. In my case (my application also heavily leaned on angular for routing and page-level templating), I couldn't mix-and-match angular and polymer and also maintain cross-browser support of the text editor. But I still am _super_ excited about the future of the webcomponents world. I mean, if nothing else, having well-namespaced element ids (if I have two editor components on the page, I can't just grab "#dateinput") will be great. I love the idea of directly attaching properties to DOM nodes, encapsulating templates, and projecting content into viewports. It's seriously rad. I am 100% on board with the notion, it's just the polyfill in the meantime that's problematical. https://github.com/webcomponents/webcomponentsjs/issues/212 https://github.com/webcomponents/webcomponentsjs/issues/212

pfooti 11y ago

Yes, I'm definitely looking forward to the Real Shadow DOM being browser-supported. I was unable to use the full webcomponents polyfill in my own application, as it introduced gamebreakers with contenteditable-based rich text editors [0]. Putting polymer anywhere on my page meant my rich text editor (quilljs fwiw) broke on non-chrome browsers, even through I wasn't doing anything polymeresque with the editor. It was just the polyfill interacting poorly with the browser's range implementation. In my case (my application also heavily leaned on angular for routing and page-level templating), I couldn't mix-and-match angular and polymer and also maintain cross-browser support of the text editor. But I still am _super_ excited about the future of the webcomponents world. I mean, if nothing else, having well-namespaced element ids (if I have two editor components on the page, I can't just grab "#dateinput") will be great. I love the idea of directly attaching properties to DOM nodes, encapsulating templates, and projecting content into viewports. It's seriously rad. I am 100% on board with the notion, it's just the polyfill in the meantime that's problematical. https://github.com/webcomponents/webcomponentsjs/issues/212 https://github.com/webcomponents/webcomponentsjs/issues/212