On Fri, Feb 8, 2013 at 11:54 AM, Scott Miles <[email protected]> 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
