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

Re: document.register and ES6

From: Daniel Buchner <daniel@mozilla.com>
Date: Thu, 7 Feb 2013 20:57:49 -0800
Message-ID: <CAHZ6zJGPD9gk1KRs5HhQNNMbhjniLhBvhG4BSZ_zT5wsFCm1ug@mail.gmail.com>
To: Scott Miles <sjmiles@google.com>
Cc: public-webapps <public-webapps@w3.org>, Erik Arvidsson <arv@chromium.org>, Boris Zbarsky <bzbarsky@mit.edu>, Dimitri Glazkov <dglazkov@google.com>
Scott is right, there isn't a great polyfill answer for this part of the
spec, but fortunately it doesn't affect too potential many use-cases.
Developers will still go bananas for the functionality we can provide in
legacy UA versions.

- Daniel
 On Feb 7, 2013 8:51 PM, "Scott Miles" <sjmiles@google.com> wrote:

> Good reminder. On webkit/ff at least, we have made polyfills which can
> generate:
>
> <x-element> // for elements derived from HTMLUnknownElement
> <button is="x-element"> // for all other elements
>
> Since both syntaxes are now (to be) supported by spec, I think we are ok?
>
> Scott
>
> P.S. 100% of the custom elements in our current library are based on
> HTMLUnknownElement.
>
> P.P.S. Arv, do you have a preference from my three versions (or none of
> the above)?
>
> On Thu, Feb 7, 2013 at 7:16 PM, Erik Arvidsson <arv@chromium.org> wrote:
>
>> Actually, that reminds me. How is a polyfill supposed to be able to
>> create an element with the tag name my-button and still have the instance
>> be an HTMLButtonElement? That does not seem possible. I guess a polyfill
>> just need to limit the base to HTMLUnknownElement.
>> On Feb 7, 2013 8:44 PM, "Scott Miles" <sjmiles@google.com> wrote:
>>
>>> In my excitement for getting something that worked on the Big Three
>>> (webkit, IE, FF), I inadvertently cheated by adding an extra parameter to
>>> 'document.register'.
>>>
>>> TL;DR version:
>>>
>>> Solutions to the extra parameter problem:
>>>
>>> 1. go ahead and have an (optional) extra parameter to document.register
>>>
>>>    MyButton = function() { ... };
>>>    MyButton.prototype = { ... };
>>>    MyButton = document.register('x-button', MyButton, 'button');
>>>
>>> 2. require user to chain prototypes himself and infer the tagName from
>>> the prototype
>>>
>>>    MyButton = function() { ... };
>>>    // making prototype requires icky DefineProperty syntax
>>>    // on IE the only purpose of chaining the prototype is for tagName
>>> inference
>>>    MyButton.prototype = Object.create(HTMLButtonElement.prototype, { });
>>>    MyButton = document.register('x-button', MyButton);
>>>
>>> 3. introduce an intermediate method to build the 'class':
>>>
>>>   MyButton = function() { ... };
>>>   MyButton.prototype = { ... };
>>>   MyButton = document.extendElement('button', MyButton);
>>>   document.register('x-button', MyButton);
>>>
>>> Right now I'm preferring (3). WDTY?
>>>
>>> ===
>>>
>>> Long version:
>>>
>>> Recall that the goal is to support the simple notion of: make class,
>>> register to tag. So,
>>>
>>>   class MyButton extends HTMLButtonElement...
>>>   document.register('x-button', MyButton);
>>>
>>> My last proposed non-ES6 version had syntax like this:
>>>
>>>    MyButton = function() { ... };
>>>    MyButton.prototype = { ... };
>>>    MyButton = document.register('x-button', MyButton, 'button');
>>>
>>> The third parameter serves two purposes: (1) allows register to chain
>>> the correct prototype (HTMLButtonElement.prototype) to MyButton.prototype
>>> and (2) allows register to generate an appropriate constructor (i.e. one
>>> the instantiates a 'button' element).
>>>
>>> Trying to remove the third parameter created some new quandries.
>>>
>>> One avenue is to suggest the developer set up the inheritance chain
>>> outside of register. This is immediately appealing because it's very close
>>> to the 'goal syntax'. IOW,
>>>
>>>    MyButton = function() { ... };
>>>    MyButton.prototype = Object.create(HTMLButtonElement.prototype, { });
>>>    MyButton = document.register('x-button', MyButton);
>>>
>>> Btw: this form requires inferring the tag name 'button' from
>>> HTMLButtonElement.prototype, which AFAIK, is not as easy as it sounds.
>>>
>>> There are two potential downsides (1) adding properties to
>>> MyButton.prototype requires property descriptors (or some helper function
>>> the user must write), (2) on IE we aren't using the chained prototype
>>> anyway.
>>>
>>> An alternative would be to introduce another method, something like
>>> 'document.extendElement'. Usage would be like so:
>>>
>>>   MyButton = function() { ... };
>>>   MyButton.prototype = { ... };
>>>   MyButton = document.extendElement('button', MyButton);
>>>   document.register('x-button', MyButton);
>>>
>>> Scott
>>>
>>>
>>> On Thu, Feb 7, 2013 at 3:15 PM, Dimitri Glazkov <dglazkov@google.com>wrote:
>>>
>>>>
>>>>
>>>>
>>>> On Wed, Feb 6, 2013 at 10:01 AM, Boris Zbarsky <bzbarsky@mit.edu>wrote:
>>>>
>>>>> On 2/6/13 5:07 PM, Erik Arvidsson wrote:
>>>>>
>>>>>> This refactoring is needed for ES6 anyway so it might be worth looking
>>>>>> into no matter what.
>>>>>>
>>>>>
>>>>> Well, yes, but it's a matter of timeframes.  It's incredibly unlikely
>>>>> that a complete refactoring of how functions are implemented (which is what
>>>>> I was given to understand would be required here) could be done in the next
>>>>> several months to a year....  I doubt we want to wait that long to do
>>>>> document.register.
>>>>
>>>>
>>>> This is a valid and important concern. Boris, in your opinion, what is
>>>> the most compatible way to proceed here? I see a couple of options, but
>>>> don't know how difficult they will be implementation-wise:
>>>>
>>>> 1) Expose the ability to override [[Construct]]. Arv tells me that he
>>>> spoke with V8 peeps and they think they can do this fairly easily. How's
>>>> the SpiderMonkey story looking here?
>>>>
>>>> 2) Until ES6 is here, return a generated constructor from
>>>> document.register, which is the approach that Scott/Arv/Daniel came up with
>>>> for polyfills. Effectively, this generated constructor will serve as the
>>>> surrogate [[Construct]] override.
>>>>
>>>> 3) ...
>>>>
>>>> 4) PROFIT
>>>>
>>>> :DG<
>>>>
>>>
>>>
>
Received on Friday, 8 February 2013 04:58:16 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:57 GMT