[webcomponents]: Invocation order of custom element readyCallback

Hi folks,

I'm implementing "readyCallback" of custom elements in WeKit.
I'm following what MutationObserver is doing, with small modification. That
is to make such calls as lazily as possible, and do it in batch. After some
trial, I started wondering what is the most desirable "invocation order" of
such delayed callbacks.

For example, think about following snippet:

div.innerHTML = "<x-parent><x-child></x-child></x-parent>";

In our curent implementation, the readyCallbacks of x-parent and x-child
are called (1) just before returning form native innerHTML implementation
to JS world, instead of (2) exactly when C++ backing objects are created.

We don't want (1): running scripts while parsing is a well-known disaster
pattern.

However, (2) seems to have its own problem:

If you (A): Call <x-parent> first and <x-child> next, does it work? This
looks straightforward and matches the order of native constructor
invocations.

One problem here is that the <x-parent> constructor can see the
uninitialized, or un-read-ified <x-child>, because <x-child> is already
inserted into <x-parent>. This breaks the illusion that says the
readyCallback is called just after the element is created.

So what about (B): Call <x-child> first and <x-parent> second? This solves
the "unreadified <x-child>" problem.

But is this what we want? For me, it seems readyCallback with
(B) unintentionally becomes more powerful than originally expected. It gets
more than just a constructor alternative. And this fact could be abused
easily. Also, the order is no longer simple enough to be explained within a
few lines.

For implementation simplicity, I prefer to pick (1) and to ask people not
to assume the children is available in readyCallback. This might make
sense; When the element is created through createElement(), we don't have
any children in readyCallback anyway. But I'm not super confident about
this.

So I would like to hear your opinion.

-- 
morrita