- From: Erik Arvidsson <arv@chromium.org>
- Date: Fri, 8 Feb 2013 12:11:44 -0500
- 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 UTC