On 1/11/15 3:13 PM, Domenic Denicola wrote:
So, at least as a thought experiment: what if we got rid of all the local name checks
in implementations and the spec. I think then `<my-q>` could work, as long as
it was done *after* `document.registerElement` calls.
Yes.
However, I don't understand how to make it work for upgraded elements at all, i.e., in the case
where `<my-q>` is parsed, and then later `document.registerElement("my-q",
MyQ)` happens. You'd have to somehow graft the internal slots onto all MyQ instances after the
fact
Yep. It's no fun.
Is there any way around this you could imagine?
Not without making the set of internal slots mutable.
Note that in some implementations (e.g. a self-hosted implementation
using WeakMaps for internal slots) this might not be so difficult. But
in general it does constrain implementation strategies quite significantly.
I know how seriously you were considering my suggestion to rewrite them all ;)
I've pretty seriously considered it on and off....
The story is still pretty unsatisfactory, however. Consider the case where your document consists of
`<my-el></my-el>`, and then later you do `class MyEl extends HTMLElement {};
document.registerElement("my-el", MyEl)`. (Note how I don't save the return value of
document.registerElement.) When the parser encountered `<my-el>`, it called `new
HTMLUnknownElement(...)`, allocating a HTMLUnknownElement. The current design says to `__proto__`-munge the
element after the fact, i.e. `document.body.firstChild.__proto__ = MyEl.prototype`. But it never calls the
`MyEl` constructor!
Yeah, I'm not a fan of this part either.
- It means that the code `class MyEl extends HTMLElement {}` is largely a lie.
I think this part of the spec was largely written before ES6 class stuff
stabilized, fwiw. Which is not hard, since it's still not stabilized. ;)
- It means that what you get when doing `new MyEl()` is different from what you got when
parsing-then-upgrading `<my-el></my-el>`.
This seems pretty undesirable.
(The same problems apply with <q is="qq">, by the way. It needs to be upgraded
from HTMLQuoteElement to QQ, but we can only `__proto__`-munge, not call the constructor.)
Hmm. So given the current direction whereby ES6 constructors may not
even be [[Call]]-able at all, I'm not sure we have any great options
here. :( Basically, ES6 is moving toward coupling allocation and
initialization but the upgrade scenario can't really be expressed by
coupled alloc+init if it preserves object identity, right?
I was hopeful that ES6 would give us a way out of this, but after thinking things
through, I don't see any improvement at all. In particular it seems you're always going
to have to have `var C2 = document.registerElement("my-el", C1)` giving `C2 !==
C1`.
This part is not immediately obvious to me. Why does that have to be true?
-Boris
