Re: Custom element design with ES6 classes and Element constructors

On Tuesday, January 27, 2015, Domenic Denicola <d@domenic.me> wrote:

> It does. If a framework says “use clonedCallback and we will implementing
> cloning for you,” we cannot add a clonedCallback with our own semantics.
>
> Whereas, if a framework says “use [Framework.cloned] and we will implement
> cloning for you,” we’re in the clear.
>
> Better yet! If a framework is a bad citizen and says “we did
> Element.cloned = Symbol() for you; now use [Element.cloned] and we will
> implement cloning for you,” we are still in the clear, since the original
> Element.cloned we supply with the browser is not === to the Element.cloned
> supplied by the framework.
>
> This last is not at all possible with string-valued properties, since the
> string “clonedCallback” is the same no matter who supplies it.


Perhaps, but that logically boils down to "never use string properties
ever" just in case some library conflicts with a different meaning. We'd
have $[jQuery.find](...) and so on for plugins.

Or more concretely isn't the new DOM Element#find() method going to
conflict with my <polymer-database>'s find() method? So why not make that
[Element.find] so polymer never conflicts?

- E