On Sun, Apr 14, 2013 at 3:46 PM, Daniel Buchner <daniel@mozilla.com> 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.*
>
> As long as the above supports all other DOM element creation vectors
> (innerHTML, outerHTML, etc), then this is fine. Practically speaking, if it
> so happened that custom elements could *never *be instantiated with
> constructors, developers on the web today wouldn't shed a tear, they use
> doc.createElement(), not constructors -->
> https://docs.google.com/forms/d/16cNqHRe-7CFRHRVcFo94U6tIYnohEpj7NZhY02ejiXQ/viewanalytics
>
> -----
>
>
> *>> 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.*
>
> Yes, it will be along time, especially for IE9 and 10 (read: never), which
> are support targets for custom element polyfills. Reliance on anything that
> is optional or future should be avoided for the custom element base case.
> Right now the polyfills for document.register(), and a few of the
> declarative proposals, can give developers these awesome APIs today -
> please, do not imperil this.
>
>
After reading Scott Miles' post here
http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0209.html, I
have a better understanding of problem caused by these generated
HTML*Element constructors: they aren't constructable. No amount of ES6
subclass support will fix that problem. The platforms need to make them
constructable—and that can't be polyfilled. I also now understand why such
great lengths have been taken to "hack" around the problem, and the
resulting "solution" with bolt-on ready* callbacks (that aren't really
callbacks, just prototype methods that will be called after some turn of
execution has initialized some element state) as stand-ins for the real
constructor function. This is somehow "ok" because it's polyfillable?
Rick