- From: Adam Klein <adamk@chromium.org>
- Date: Mon, 4 Jul 2011 14:02:32 -0700
- To: Olli@pettay.fi
- Cc: Ojan Vafai <ojan@chromium.org>, Boris Zbarsky <bzbarsky@mit.edu>, public-webapps@w3.org
On Mon, Jul 4, 2011 at 1:45 PM, Olli Pettay <Olli.Pettay@helsinki.fi> wrote: > On 07/04/2011 08:16 PM, Adam Klein wrote: >> On Mon, Jul 4, 2011 at 9:57 AM, Olli Pettay<Olli.Pettay@helsinki.fi> >> wrote: >>> On 07/04/2011 07:28 PM, Ojan Vafai wrote: >>>> The only bit that might be slower is what data you include in the >>>> mutation list. I believe that all the data you'd need is cheap except >>>> for possibly the following two: >>>> -The index of the child that changed for ChildListChanged (is this >>>> actually expensive?) >>> >>> You may need more than just an index. element.innerHTML = null removes >>> all the child nodes. >>> And element.inserBefore(some_document_fragment, element.lastChild) >>> may insert several child nodes. >>> Depending on whether we want to get notified for each mutation >>> or batch the mutations, simple index may or may not be enough. >> >> Would a node reference be better ("nextSibling")? Assuming the >> listeners have access to all inserted/removed nodes along the way, >> using another as an anchor seems like it would work properly (though >> the innerHTML case may need something special). > > Where would the node reference be? > What would the API look like? In Rafael's API, each mutation is represented by an object, so I'd simply put it there with its own key, something like: interface MutationRecord { // e.g., 'ChildListChanged', 'AttributeChanged' readonly attribute DOMString type; // element whose childNodes changed, or whose attribute was changed readonly attribute Node target; readonly attribute NodeList insertedNodes; readonly attribute NodeList removedNodes; // reference to the node before which the above nodes were removed/inserted readonly attribute Node nextSibling; }; With your API, I think you'd want to change from passing nodes to the callback to using something like the above, analogous to the information hanging off of MutationEvent in the current spec. - Adam
Received on Tuesday, 5 July 2011 11:56:56 UTC