On 1/12/15 7:24 PM, Domenic Denicola wrote:
One crazy idea for solving B is to make every DOM element (or at least, every one
generated via parsing a hyphenated or is="" element) into a proxy whose target
can switch from e.g. `new HTMLUnknownElement()` to `new MyEl()` after upgrading. Like
WindowProxy, basically. I haven't explored this in much detail because proxies are scary.
Hey, we have implementation experience for this in Gecko, since that's
_exactly_ what we do when you adopt an element into a different global:
we replace the guts of the old object with a proxy to the new thing. ;)
Some thoughts:
1) This does NOT affect C++ references in Gecko, not least because the
C++ object identity doesn't change in this case. Updating those would
be a PITA. But you want to change the C++ object identity for this
particular use case, so you could get into weird situations where if
something that's not JS is holding a ref to your element it can now be
pointing to the wrong element. Unless things get changed so all C++
holds references to elements via their JS reflections, which is probably
a nonstarter.
2) There is a performance penalty for having a proxy, obviously. For
adoption this is not too horrible, since in practice that's not that
common, but presumably upgrades would actually be somewhat common.
3) You need a way for the brand checks Web IDL methods do to deal with
these proxies. Gecko already has a way for that to work, on a slower
path, since we have these membrane proxies, but other UAs would need to
grow something like that.
-Boris
