Re: document.register and ES6

To be clear, the actual current spec is only:

var MyButton = document.register('my-button', {
  prototype: aPROTOTYPE
});

So, while Arv has included non-spec 'created' and 'attributeChanged', you
have completely omitted 'prototype'.

Also, wrt "call methods on the custom element", I believe all Arv means is
that instead of registering an explicit callback function (e.g.
attributeChanged), we could implicitly register that function by including
it in the prototype.

He's not suggesting some big alteration of the basic behavior afaik.

Scott



On Wed, Feb 6, 2013 at 10:06 AM, Daniel Buchner <daniel@mozilla.com> wrote:

>
>
> On Wed, Feb 6, 2013 at 9:03 AM, Erik Arvidsson <arv@chromium.org> wrote:
>
>> On Tue, Feb 5, 2013 at 8:26 PM, Daniel Buchner <daniel@mozilla.com>
>> wrote:
>> > I have two questions:
>> >
>> > Does this affect our ability to polyfill doc.register in current
>> browsers?
>>
>> Good point. This is really important to us as well so we most likely
>> need to tweak this to make sure it will work.
>>
>> Do we need to be able to do "new MyButton" or is
>> document.createElement/innerHTML/parser sufficient? If we need to be
>> able to do "new" in the polyfill I think we either need to tweak
>> document.register or get the developer to cooperate (by writing
>> different code). At this point I don't see how we can tweak the API
>> and still fulfill all of the requirements.
>>
>> > Are you saying we're going to nix the ability to easily register
>> insertion,
>> > removal, and attribute change callbacks from the API?
>>
>> No. I don't think there is any change here. Instead of passing in
>> functions to document.register we can call methods on the custom
>> element. For example:
>>
>> class MyButton extends HTMLButtonElement {
>>   constructor() {
>>     super();
>>     this.moreInit();
>>   }
>>   handleAttributeChange(name, value) { ... }
>>   moreInit() { ... }
>>   ...
>> }
>> document.register('my-button', MyButton);
>>
>
> Above you say the developer would simply "call methods on the custom
> element" - how do you figure? Are we going to imbue all elements with
> magical handleRemoved, handleAttributeChange, etc function handlers that,
> when simply defined in the closure, implicitly hook into mutation
> observations? I hope this isn't the case, as it would be incredibly obtuse
> and extremely magical. If that's not what you mean, please provide a full
> example that leaves out none of the boilerplate - I would like to see what
> developers are really in for.
>
> You start the following code section below with "instead of" below, but
> nothing below this point accurately represents how the spec currently
> behaves
>
>
>> instead of
>>
>> var myButtonPrototype = Object.create(HTMLButtonElement.prototype, {
>>   handleAttributeChange: {
>>     value: function(name, value) { ... },
>>     enumerable: true,
>>     configurable: true,
>>     writable: true
>>   },
>>   moreInit: {
>>     value: function() { ... },
>>     enumerable: true,
>>     configurable: true,
>>     writable: true
>>   },
>>   ...
>> });
>>
>> var MyButton = document.register('my-button', {
>>   prototype:" myButtonPrototype,
>>   created: function(element) {
>>     element.moreInit();
>>   },
>>   attributeChange: function(element, name, value) {
>>     element.handleAttibuteChange(name, value);
>>   }
>> });
>>
>
> Currently it is:
>
> var MyButton = document.register('my-button', {
>     lifecycle: {
>         attributeChanged: function(){ ... }
>     }
> });
>