[webcomponents]: Timing of custom elements callbacks

Dear WebAppenterns,

The timing of custom element callbacks is tricky. The naive first shot
at specifying them
(https://dvcs.w3.org/hg/webcomponents/raw-file/723367db9fa7/spec/custom/index.html)
was too, well.. naive. Turns out, custom elements callbacks are not
like mutation observer records. The failure of expectations is
illustrated by this simple example:

/* 1 */ div.innerHTML = '<zotoh-zhaan></zotoh-zhaan>';
/* 2 */ div.firstChild.levelUp();

Let's pretend that "levelUp" is a totally legit method on
<zotoh-zhaan>'s prototype.

Per spec, this method will be called after the readyCallback on
<zotoh-zhaan> is invoked, since the callbacks are invoked at a
microtask checkpoint.

However, web developers (both developers and consumers of
<zotoh-zhaan>) expect that a method on a custom element instance are
called after this instance is initialized--which is the whole purpose
of the readyCallback!

That's what we call a juicy contradiction. A small bunch of us (cc'd)
dwelled on this problem a bit (see discussion on
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22459). Finally, we
came up with a proposal, outlined in
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22459#c10 (the last
paragraph).

By employing the scoped callback queues, described in the proposal,
we're able to ensure that the callbacks are still handled in a safe
(read "non-Mutation-events-style") manner, but appear sane to web
developers.

Going an extra metra, my-hero-for-the-next-5-days Dominic already
implemented it in Blink to proof the concept. He documents his finding
in comment 15 of the bug
(https://www.w3.org/Bugs/Public/show_bug.cgi?id=22459#c15).

Please look over the idea, play with it in Chrome Canary, and feed
your (valuable parts of) stream of consciousness back here.

:DG<

Received on Friday, 12 July 2013 22:13:24 UTC