Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

No, I believe this is *precisely *the thing to worry about - these nits and
catch-case gotchas are the sort of things developers see in an emerging
API/polyfill and say "awe, that looks like an fractured, uncertain hassle,
I'll just wait until it is native in all browsers" <-- we must avoid this
at all cost, the web needs this *now*.

Daniel J. Buchner
Product Manager, Developer Ecosystem
Mozilla Corporation


On Thu, Feb 14, 2013 at 3:16 PM, Dimitri Glazkov <dglazkov@google.com>wrote:

> On Thu, Feb 14, 2013 at 2:53 PM, Scott Miles <sjmiles@google.com> wrote:
>
> > Well, yes, here ya go: (o). But I must be missing something. You wouldn't
> > propose two APIs if they were equivalent, and I don't see how these are
> not
> > (in any meaningful way).
>
> The only difference is that one spits out a generated constructor, and
> the other just returns a constructor unmodified (well, not in a
> detectable way). My thinking was that if we have both be one and the
> same API, we would have:
>
> 1) problems writing specification in an interoperable way ("if you can
> override [[Construct]] function, then do this...")
>
> 2) problems with authors seeing different effects of the API on each
> browser ("in Webcko, I get the same object as I passed in, maybe I
> don't need the return value, oh wait, why does it fail in Gekit?")
>
> Am I worrying about this too much?
>
> :DG<
>