- From: Erik Arvidsson <arv@google.com>
- Date: Thu, 15 Jan 2015 11:02:08 -0500
- 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 https://github.com/domenic/element-constructors/blob/master/element-constructors.js#L88 >> 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. -- erik
Received on Thursday, 15 January 2015 16:03:06 UTC