- From: <bugzilla@jessica.w3.org>
- Date: Thu, 06 Jun 2013 05:22:18 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22288 Dominic Cooney <dominicc@chromium.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mrbkap@gmail.com, | |sjmiles@chromium.org, | |sorvell@chromium.org, | |w3c@adambarth.com, | |wchen@mozilla.com --- Comment #1 from Dominic Cooney <dominicc@chromium.org> --- 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. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Thursday, 6 June 2013 05:22:24 UTC