W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2013

Re: document.register and ES6

From: Erik Arvidsson <arv@chromium.org>
Date: Fri, 8 Feb 2013 12:11:44 -0500
Message-ID: <CAJ8+Goj-pMazG4phvTZOSSWGy=mY2=uB22DdHJ1qyZ40jy-0mA@mail.gmail.com>
To: Scott Miles <sjmiles@google.com>
Cc: public-webapps <public-webapps@w3.org>, daniel <daniel@mozilla.com>, Boris Zbarsky <bzbarsky@mit.edu>, Dimitri Glazkov <dglazkov@google.com>
On Fri, Feb 8, 2013 at 11:54 AM, Scott Miles <sjmiles@google.com> wrote:
> The idea is supposed to be that 1 and 3 are only stopgaps until we get 'what
> we want'. In the future when you can derive a DOM element directly, both
> bits of extra code can fall away. Was that clear? Does it change anything in
> your mind?
>
> If we go with 2, I believe it means nobody will ever use a custom element
> without having to load a helper library first to make the nasty syntax go
> away, which seems less than ideal. I donno, I'm not 100% either way.

1 and 3 have nasty syntax too so until you can depend on ES6 you
probably want to use a helper function no matter what.

var MyElement = defineClass(HTMLElement, {
  constructor: function() {},
  method: function() {},
  get prop() {},
  set prop(v) {}
});
MyElement = document.register('my-element', {
  class: MyElement
});

I believe a polyfill would most likely actually just be a shim (in the
terms we have started to use) because:

1. We cannot really extends anything else but HTMLElement/HTMLUnknownElement.
2. We cannot return the correct function object from document.register.
3. We cannot setup the [[Prototype]] in IE.
4. The fixup is async at best

and since it just a shim you might as just impose extra restrictions
on the usage. These extra restrictions could be to use helper
functions.

-- 
erik
Received on Friday, 8 February 2013 17:12:32 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:57 GMT