This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
There is a jsbin <http://jsbin.com/arizup/2/edit> which illustrates that this author expects the ready, inserted and removed callbacks to be invoked synchronously. However the spec as written says these are run at a microtask checkpoint. Implementers are often concerned about adding synchronous callbacks in response to DOM modifications because of difficulties with Mutation Events. In theory their concerns can be addressed by treating modifications arising from script operations and modifications arising from parsing differently. The precise timing of the callbacks can be not during the tree modification itself, but when control is about to return to script (so the UA is "running script anyway" at approximately that point.) For example, in the jsbin case above, the call to node.remove could run lifecycle events after the UA has modified the DOM, but before execution returns to the script engine.
CCing some web developers and UA implementers who I know have strong feelings about this. Let me sketch a more concrete proposal: We go through DOM spec and HTML spec and come up with a set of tree-mutating operations and attributes: prepend, append, before, after, replace, remove, insertBefore, appendChild, replaceChild, removeChild, setAttribute, setAttributeNS, removeAttribute, removeAttributeNS, innerHTML, textContent and reflected attributes (Did I miss some? What about DOMTokenList/DOMSettableTokenList?) Custom Elements legislates an additional step at the end of these to invoke lifecycle callbacks. My claim that this is OK, where Mutation Events were a world of hurt, because during the operation the UA is just enqueuing a callback similar to the way it would a mutation record. And although it is processing the record synchronously, that happens at a point when the UA is going to return to script. The analogy in Mutation Observers is as if the script called takeRecords at that point. One question is what to do with recursion. For example I believe it would be weak if (to borrow a snippet from <http://jsbin.com/arizup/2/edit>) node.remove(); console.log('upgraded:', node.isXFoo); console.log('ready', node.ready, 'expected', 1); console.log('inserted', node.inserted, 'expected', 1); console.log('removed', node.removed, 'expected', 1); behaved differently depending on whether that code ran in the context of an existing lifecycle event callback or not (because the running lifecycle callbacks flag will bail out.) I'm hoping that the recursion guard is generalized to be for all microtask checkpoint tasks and it goes away from the Custom Elements spec, and the Custom Elements spec can eagerly chew through lifecycle callbacks at the points described above without a recursion flag.
The substantive discussion about synchronous callbacks or not is happening on bug 21969. *** This bug has been marked as a duplicate of bug 21969 ***