I almost forgot, there is a secondary problem with 'normal constructors', see here:
http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0728.html Sorry in advance, lol. On Sun, Apr 14, 2013 at 12:22 PM, Scott Miles <sjmi...@google.com> wrote: > errata: XFooPrototype = Object.create(HTMLElement.prototype, { > > > On Sun, Apr 14, 2013 at 12:21 PM, Scott Miles <sjmi...@google.com> wrote: > >> >> Alex Russell have been advocating that WebIDL should be allow >> constructor-like interfaces >> >> Absolutely agree. But these are horns of this dilemma. >> >> >> #4 has been accepted for ES6 by all TC39 participants >> >> Yes, I believe this is a timing issue. I am told it will be a long time >> before #4 is practical. >> >> Gecko and Blink have already landed forms of 'document.register', to wit: >> >> Grail-shaped version of document.register: >> >> // use whatever 'class-like' thing you want >> >> class XFoo extends HTMLElement { >> constructor() { >> super(); >> this.textContent = "XFoo Ftw"; >> } >> } >> document.register('x-foo', XFoo); >> >> >> But since (today!) we cannot extend HTMLElement et al this way, the >> landed implementations use: >> >> // prototype only >> >> XFooPrototype = Object.create(HTMLElement, { >> >> readyCallback: { >> value: function() { // we invented this for constructor-like semantics >> >> super(); // some way of doing this >> >> } >> } >> >> }; >> >> // capture the constructor if you care >> >> [XFoo =] document.register('x-foo', {prototype: XFooPrototype); >> >> >> Which for convenience, I like to write this way (but there are footguns): >> >> class XFooThunk extends HTMLElement { >> >> // any constructor here will be ignored >> >> readyCallback() { // we invented this for constructor-like semantics >> >> super(); >> >> } >> >> } >> >> // capture the real constructor if you care >> >> [XFoo =] document.register('x-foo', XFooThunk); >> >> >> >> On Sun, Apr 14, 2013 at 12:07 PM, Allen Wirfs-Brock < >> al...@wirfs-brock.com> wrote: >> >>> >>> On Apr 14, 2013, at 11:40 AM, Scott Miles wrote: >>> >>> >> Here are four ways to avoid the subclassing problem for custom >>> elements >>> >> 1) Only allow instances of custome dom elements to be instantiated >>> using document.createElement("x-foo"). >>> >>> Wearing web developer hat, I never make elements any other way than >>> createElement (or HTML), so this would be standard operating procedure, so >>> that's all good if we can get buy in. >>> >>> >>> However, I believe that some people such as Alex Russell have been >>> advocating that WebIDL should be allow constructor-like interfaces to >>> support expressions such as: >>> new HTMLWhateverElement() >>> >>> It would be future hostile to make that impossible, but support could >>> reasonably wait for ES6 support. >>> >>> >>> >> 2, 3, 4 >>> >>> I believe have been suggested in one form or another, but as I >>> mentioned, were determined to be non-starters for Gecko. I don't think >>> we've heard anything from IE team. >>> >>> >>> Well #4 has been accepted for ES6 by all TC39 participants including >>> Mozilla and Microsoft and is going to happen. The basic scheme was >>> actually suggested a member of the SpiderMonkey team so I'm sure we'll get >>> it worked out for Gecko. >>> >>> Allen >>> >>> >>> >> >