- From: Anne van Kesteren <annevk@opera.com>
- Date: Mon, 05 Dec 2011 16:32:29 +0100
- To: "www-dom@w3.org" <www-dom@w3.org>
As discussed mutation observers would be best defined in the DOM. The DOM is discussed on www-dom@w3.org: http://lists.w3.org/Archives/Public/www-dom/ (I bcc'd public-webapps just in case anyone missed this.) I think I now defined the last hook needed for mutation observers, "replace all". The hooks related to tree mutations are defined here: http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#mutation-algorithms To illustrate: * appendChild(node) maps to the "append" algorithm, which invokes "pre-insert", which eventually does "insert". * setting textContent maps to the "replace all" algorithm, which invokes "remove" (for each child node) followed by a single "append" * setting innerHTML can be defined just like textContent, using a DocumentFragment for the nodes to be inserted Whether separate "pre-insert" and "insert" is really necessary depends on how we end up defining mutation observers. I'm not sure what the current status of mutation observers is, but one open question was whether we should special case the "style" attribute due to it being frequently mutated. Has any data been gathered on that already? I have another question, if we expect a lot of mutations, should we split MutationRecord for the attribute/characterData versus childList case? There's a bunch of members that do not make sense for either of those. Mutation observer IDL is currently maintained here: http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#mutation-observers -- Anne van Kesteren http://annevankesteren.nl/
Received on Monday, 5 December 2011 15:33:10 UTC