On 07/05/2011 12:02 AM, Adam Klein wrote:
On Mon, Jul 4, 2011 at 1:45 PM, Olli Pettay<olli.pet...@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.pet...@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;
};
And nextSibling would be null in case of appendChild, I guess.
(Not related to nextSibling)
Handling of insertedNodes/removedNodes becomes tricky if there are
several listeners and the first one of those adds or removes child
nodes. Should the listeners which will be called later get the same
insertedNodes/removedNodes as the first listener, or should the lists be
updated to reflect what has actually changed?
If the notification just tells that something has changed, it would be
up to the JS side to implement the kind of list handling it wants.
-Olli
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
