- From: Daniel Buchner <daniel@mozilla.com>
- Date: Thu, 7 Feb 2013 20:57:49 -0800
- 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>
- Message-ID: <CAHZ6zJGPD9gk1KRs5HhQNNMbhjniLhBvhG4BSZ_zT5wsFCm1ug@mail.gmail.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 UTC