Re: Mutation events replacement

On 07/05/2011 12:02 AM, Adam Klein wrote:
> 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;
> };

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
>

Received on Monday, 4 July 2011 21:23:21 UTC