Custom elements backing swap proposal

I've been thinking about ways to make custom elements violate the
consistency principle less often and had a pretty awesome idea recently.

Unfortunately I won't be at TPAC, but I'd like to discuss this idea in
person. Can we setup a custom element discussion later in the year?

The current  "synchronous in the parser" model doesn’t feel good to me
because cloneNode() and upgrades are still async, and I fear other things
(ex. parser in editing, innerHTML) may need to be as well. So, while we've
covered up the inconsistent state of the element in one place (parser),
we've left it to be a surprise in the others which seems worse than just
always being async. This led me to a crazy idea that would get us
consistency between all these cases:

What if we use a different pimpl object (C++ implementation object) when
running the constructor, and then move the children/shadows and attributes
after the fact? This element can be reused (as implementation detail), and
any attempt to append it to another element would throw.

An example algorithm for created callback is:
https://gist.github.com/esprehn/505303896aa97cd8b33e

In an engine you could imagine doing this by creating a new C++ Element
with the same tag name, having the JS wrapper point to it, running the
constructor, merging the new C++ element data with the original C++ element
data, and then associating the wrapper back to the original C++ element.
Note that during this time the original C++ element, and the temp one both
point to the same wrapper, but the wrapper only points to the temp one.
This ensures that any held references to MutationRecords/Events or other
objects will also observe the temporary state change.

This is similar to Maciej’s idea of removing the elements from the tree and
removing their attributes before running the callback, then adding them
back after, but it avoids having to actually remove the elements and update
the associated tree state.

There's lots of details to work out here, but I think this could be
workable. The hardest part is making the swapping step robust in the
engine, for example the internal Attr objects would need to handle the
ownerElement.

- E