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
>
Of course, but we'd also eat scraps from the trash if that was the only
edible food left on earth. document.createElement() is and has always been
"the wrong way"—the numbers shown in those graphs are grossly skewed by a
complete lack of any real alternative.
If I want to make a new button to put in the document, the first thing my
JS programming experience tells me:
new Button();
But I live in the "bad old days" (assuming my children won't have to use
garbage APIs to program the web) and my reality is still here:
document.createElement("button");
This indicates nothing about state or initialization. And of course
developers are going to fill out a survey and say they use this API—there
isn't any other API to use! It would be awkward to have a few new Image()
or new Option() expressions sprinkled around your code—unless all element
instantiation looked like that, then it would be the status quo and that
survey would have very different results.
>
> -----
>
>
> *>> 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.
>
>
And progress suffers.
Rick