>> This is somehow "ok" because it's polyfillable?
The polyfill thing is a red-herring, let's not cloud the issue.
>> The platforms need to make them constructable
Agreed, but the estimates are months or years to make it so, which is too
long to block these features.
>> "hack" around the problem
Many good people have been trying to solve this over-constrained problem
for months. I don't think this is a fair characterization.
>> bolt-on ready* callbacks
The 'callback' naming and semantics were the result of a long debate. Can
you make your objections clearer? Also, please refer to this thread
http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0728.html for
more information about 'readyCallback' in particular.
On Sun, Apr 14, 2013 at 2:35 PM, Rick Waldron <waldron.rick@gmail.com>wrote:
>
>
>
> 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
>
>
>