As discussed mutation observers would be best defined in the DOM. The DOM
is discussed on www-...@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/