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. -- erikReceived 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