It's not quite that simple but I think that both of you are right. In an ideal case, the custom element should be indistinguishable from a native element.
The problems start when frameworks and libraries make assumptions about DOM that were true before custom elements, but are no longer valid now. For example, in the past creating an element could have been done without worrying about any side effects because most of the html elements are lightweight. With custom elements, nobody knows what happens when an element is instantiated and bad things might happen if the framework creates an element just for bookkeeping purposes, creates it too early, pools elements or does other things where the were harmless with native elements, but with custom elements could result in bad side-effects. Another issue are assumptions about behavior of global and boolean attributes in DOM. Something that was not an issue before custom elements, but as we've already seen is an issue now. The data-binding aspect of interop is a completely different story and just as before the issue is that in the past it was sufficient to bind to attributes, but with custom elements you quickly start hitting walls if you go down this path. I expect that if they haven't already, sooner or later Ember will come across similar issues as those that Angular came across already. \i On Wed Nov 12 2014 at 2:35:19 PM 'Matthew McNulty' via Polymer < [email protected]> wrote: > If your framework allows for the use of standard HTML elements, it will > also work with custom elements in supported browsers, modulo bugs or > optimizations that don't take the very existence of new HTML tags into > account. > > If your framework requires coordination from within the boundaries of an > element to an outside orchestrator via non-standard APIs (read: not > properties, attributes, events, and children), it's not that simple. > > Custom elements have the same API surface area as native elements. > > Having some sort of component system that could describe a non-standard > API such that any component could work with some non-standard orchestration > system that isn't the DOM is a completely separate question. > > -Matt > > On Wed, Nov 12, 2014 at 2:16 PM, Rob Eisenberg < > [email protected]> wrote: > >> Once again, I restate what I said before: custom elements are not >> necessarily compatible with any framework. >> >> The original poster is asking about Ember and Handlebars. He's not asking >> about basic DOM capabilities like attributes, properties, etc. The fact >> that there is no standard for data-binding is an important part of the "any >> framework" aspect of the question. The poster wants to know if he can use >> custom elements with any framework and have it all work correctly, >> especially frameworks that support databinding like Ember. The answer to >> that question is no. Some things might work, others might not. It will >> probably depend on the framework. As I said, it won't work correctly with >> Angular 1.x. If that isn't a concrete example, I'm not sure what is. Now, >> I'm less familiar with Ember, so I'm not sure if they have that problem as >> well. Maybe not. >> >> Incidentally, the problem isn't a lack of a databinding standard. The >> problem is that the web components spec doesn't include any notion of >> metadata or self-describing components. Many would say that is an essential >> aspect of any component system. I've worked with many component systems >> over the years and web components is the first that seems to be missing >> that piece. If that were added to HTML, then it would be much easier to >> build binding systems like Angular's and Ember's and to ensure they work >> properly with anything. A lot of other interesting things would also be >> possible, of course. >> >> On Wednesday, November 12, 2014 4:56:08 PM UTC-5, Scott Miles wrote: >>> >>> >> Actually, no, custom elements are most definitely not theoretically >>> compatible with any framework >>> >>> This is not accurate from our perspective. Custom elements are >>> fundamentally indistinguishable from native elements and therefore work in >>> any DOM context. >>> >>> >> This is one of several reasons that Angular has to make big breaking >>> changes in 2.0 and why other libraries with databinding support will >>> probably follow in some fashion or another. >>> >>> There is no standard for data-binding. >>> >>> One can say, Angular doesn't support data-binding to Custom Elements, >>> but this is no fault of Custom Elements. >>> >>> It might also be true to say, Polymer's data-binding doesn't support >>> framework X. This also has nothing to do with Custom Elements, and again >>> reflects only the lack of a data-binding standard. >>> >>> Custom Elements support attributes, properties, events, and children, >>> the same as native elements. >>> >>> Scott >>> >>> On Wed, Nov 12, 2014 at 5:26 AM, Rob Eisenberg < >>> [email protected]> wrote: >>> >>>> Actually, no, custom elements are most definitely not theoretically >>>> compatible with any framework. Not out of the box at least. This is one of >>>> several reasons that Angular has to make big breaking changes in 2.0 and >>>> why other libraries with databinding support will probably follow in some >>>> fashion or another. >>>> >>>> On Tuesday, November 11, 2014 5:49:31 PM UTC-5, Eric Bidelman wrote: >>>>> >>>>> Theoretically, custom elements are compatible with any framework. >>>>> >>>>> https://www.polymer-project.org/docs/start/customelements.html#interop >>>>> >>>>> On Wed, Nov 12, 2014 at 9:18 AM, Christopher Dumas <[email protected] >>>>> > wrote: >>>>> >>>>>> I am a huge fan of Google's Material Design (and I think >>>>>> Polymer is really cool), and also of Ember.JS. I was interested to know >>>>>> whether you plan to have compatibility with Ember.JS. To clarify: I was >>>>>> hoping that Polymer might at least play nicely with Ember and Handlebars. >>>>>> Keep up the good work! >>>>>> >>>>>> Follow Polymer on Google+: plus.google.com/107187849809354688692 >>>>>> --- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Polymer" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> To view this discussion on the web visit https://groups.google.com/d/ >>>>>> msgid/polymer-dev/CD4C3C6E-FA6D-466E-ADAA-A3732FDBFE42%40me.com. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> Follow Polymer on Google+: plus.google.com/107187849809354688692 >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "Polymer" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To view this discussion on the web visit https://groups.google.com/d/ >>>> msgid/polymer-dev/6fd8b32c-975f-4f65-89bd-5128db29d8bd% >>>> 40googlegroups.com >>>> <https://groups.google.com/d/msgid/polymer-dev/6fd8b32c-975f-4f65-89bd-5128db29d8bd%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> Follow Polymer on Google+: plus.google.com/107187849809354688692 >> --- >> You received this message because you are subscribed to the Google Groups >> "Polymer" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/polymer-dev/f4da903e-e2df-4c3a-96f8-9bd3cddb666a%40googlegroups.com >> <https://groups.google.com/d/msgid/polymer-dev/f4da903e-e2df-4c3a-96f8-9bd3cddb666a%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > Follow Polymer on Google+: plus.google.com/107187849809354688692 > --- > You received this message because you are subscribed to the Google Groups > "Polymer" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/polymer-dev/CAKrkLHpQtsD9d8fqkmBqpBZzBavPBt%2B1wekJW7cD02wX97KBVA%40mail.gmail.com > <https://groups.google.com/d/msgid/polymer-dev/CAKrkLHpQtsD9d8fqkmBqpBZzBavPBt%2B1wekJW7cD02wX97KBVA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > Follow Polymer on Google+: plus.google.com/107187849809354688692 --- You received this message because you are subscribed to the Google Groups "Polymer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CAO9zZYNdQ3LA3jyz-u0fcR7AkDxaK7wtym4zNpk7-6PuDhRqyg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
