- From: Scott Miles <sjmiles@google.com>
- Date: Thu, 7 Feb 2013 20:51:26 -0800
- To: Erik Arvidsson <arv@chromium.org>
- Cc: public-webapps <public-webapps@w3.org>, daniel <daniel@mozilla.com>, Boris Zbarsky <bzbarsky@mit.edu>, Dimitri Glazkov <dglazkov@google.com>
- Message-ID: <CAHbmOLZQop9q_NSYngyQHhfSGB4mjj8eBga=F-0x84432zLqCw@mail.gmail.com>
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:51:55 UTC