W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2015

Re: Custom element design with ES6 classes and Element constructors

From: Elliott Sprehn <esprehn@google.com>
Date: Tue, 27 Jan 2015 21:17:46 -0800
Message-ID: <CAO9Q3i+BC4zYnsXOYNUC=ONSNf+gyV3FnWX6xWXzMbrce_c18g@mail.gmail.com>
To: Domenic Denicola <d@domenic.me>
Cc: Yehuda Katz <wycats@gmail.com>, Dimitri Glazkov <dglazkov@google.com>, Erik Arvidsson <arv@google.com>, Dmitry Lomov <dslomov@chromium.org>, WebApps WG <public-webapps@w3.org>
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
Received on Wednesday, 28 January 2015 05:18:13 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:25 UTC