Re: Mutation events replacement

On Mon, Jul 4, 2011 at 2:22 PM, Olli Pettay <Olli.Pettay@helsinki.fi> wrote:

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

All remaining listeners should get the same list of MutationRecords but we
should add new MutationRecord to the list for the mutation made by the first
listener.

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.
>

So when the "flag is off", we won't have insertedNodes, removedNodes, and
nextSibling but still have type and element, right?

- Ryosuke