Re: Mutation events replacement

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