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

Re: Custom element design with ES6 classes and Element constructors

From: Erik Arvidsson <arv@google.com>
Date: Thu, 15 Jan 2015 11:02:08 -0500
Message-ID: <CAJ8+GojSpga_pu+bY3CtCz-vZ+B8kooqEy+_508X3xUd9EExeg@mail.gmail.com>
To: Dmitry Lomov <dslomov@chromium.org>
Cc: Yehuda Katz <wycats@gmail.com>, Domenic Denicola <d@domenic.me>, WebApps WG <public-webapps@w3.org>
On Thu, Jan 15, 2015 at 1:09 AM, Dmitry Lomov <dslomov@chromium.org> wrote:
> On Thu, Jan 15, 2015 at 5:11 AM, Yehuda Katz <wycats@gmail.com> wrote:
>> On Wed, Jan 14, 2015 at 3:47 PM, Domenic Denicola <d@domenic.me> wrote:
>> Isn't this at least a little future-hostile to things like `new
>> MyElement(attrs)`? Is there a way we could get back to that in the future,
>> in your mind?
> If this is what is desired, HTMLElement can pass all its arguments to
> createdCallback, i.e. call createdCallback(...args) in its constructor.
> Since default constructors pass all their arguments upstream,
>    new MyElement(attrs)
> will pass attrs as arguments to HTMLElement constructor. HTMLElement
> constructor needs no arguments itself, so it will pass all of those to
> MyElement's createdCallback.

Another option is to provide a species function, which would be what
the UA calls.

One of the problems with just forwarding the args is that the default
arguments to HTMLElement constructor already has a bunch of
parameters, as in the strawman at

>> Can you say more about why same-identity upgrading is critical to the
>> design (as opposed to dom-mutation upgrading)? I asked up-thread but didn't
>> get any takers.

I think these points have been pointed out before but I'll list them again:

 * Identity - Elements used as keys in maps etc
 * Hidden state - cloneNode copies some internal state but generally
not enough (scroll position, selection, event listeners etc)
 * Mutation record spam
 * JS properties that are not reflected are lost

>>> On a final note, we could further bikeshed the name of createdCallback(),
>>> e.g. to either use a symbol or to be named something short and appealing
>>> like initialize() or create(), if that would make it even more appealing :)
>> I think symbols are actually pretty important here.
>> To elaborate, I envision a future where Ember tries to move its Component
>> API to be "just a DOM subclass". So when you inherit from Ember's
>> `Component`, you're actually inheriting from a DOM `HTMLElement` too.
>> document.register('my-element', class extends EmberComponent {
>> });
>> But Ember already has a whole suite of methods and properties on
>> `Ember.Component`, some of which may accidentally conflict with these
>> callbacks (now and in the future).
>> More generally, once people start writing libraries of HTMLElement
>> subclasses, our ability to add new callback names for all elements is going
>> to become pretty dicey, and we'll probably be forced into symbols anyway. We
>> may as well avoid a future inconsistency and just namespace DOM-supplied
>> callbacks separately from user-supplied properties and methods.

I'm sympathetic to this but I think it is fine that DOM continues to
define new string based property names. Anytime we add a new property
to an existing class we run into this issue and I don't think we want
to give up on the superior usability of string based property names.

Received on Thursday, 15 January 2015 16:03:06 UTC

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