webcomponentsjs

you serious issue IS merged https://github.com/webcomponents/webcomponentsjs/pull/644 ;-) Also its NOT polymer issue - it is polyfill issue. It affects things like x-tag,bosonic and others. ANyways it looks like latest release is the fixed version.

I have recently decided to switch from Polymer to Material2 for the following reasons: - Polymer is only available through bower, which means I have to teach 2 package management systems to my developers. - The documentation is not great (for instance, events are documented in camelCase, but must be listened for in Angular 2 using dashes-between-words). - There are serious issues [0] which not gone resolved for a long time. - The behavior of important components is not intuitive. For instance, the menu component acts more like a list which has a selected item (which also cannot be reselected) [0]: https://github.com/webcomponents/webcomponentsjs/issues/541

Polymer is not a polyfill, it uses the webcomponentsjs polyfills: https://github.com/webcomponents/webcomponentsjs

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 tw

Start with this: https://github.com/webcomponents/webcomponentsjs/issues/212 Which is why I stopped messing around with polymer. Basically adding the webcomponents polyfill to your DOM tree (because it touches so many things) breaks contenteditable in some weird ways. Which can be limiting to people who use rich text editors (many still decorate contenteditable divs) although iframe-wrapping the editor fixes the contenteditable breakage (at the expense of introducing other problems with extending your editor - try adding custom (say) atmention autocompletes to something in its own execution context). Also, webcomponents have had some pretty major syntax changes over time, especially when it comes to shadow-piercing styling vs other styling selectors. Ultimately, I'm looking forward to webcomponents. I can't wait to have proper namespaces

The web components polyfills have support down to IE 10: https://github.com/webcomponents/webcomponentsjs

Chrome already supports the v0 Shadow DOM spec, and will soon support v1. Edge(nee IE) and Firefox are committed to support and active in the standards discussions, and I believe allocating people to work on it, if not working on it already. Support across all the major browsers will arrive before we know it. We also have polyfills for Shadow DOM and the other Web Components standards, and are updating them for the v1 spec: https://github.com/webcomponents/webcomponentsjs The Shadow DOM polyfill is a bit slow, but soon it'll only be necessary on older browsers, so some properties might be able to adopt full Shadow DOM within the year. If you use Polymer, we have a fast Shadow DOM-like shim called Shadey DOM, and you can pretty seamlessly opt-in to full Shadow DOM where available.