W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: Mutation events replacement

From: Ryosuke Niwa <rniwa@webkit.org>
Date: Tue, 5 Jul 2011 09:15:41 -0700
Message-ID: <CABNRm634NSYJ0GU43hHLOT68q9oE-sHAqz_2ha8iOMJ2c2XC+Q@mail.gmail.com>
To: Olli@pettay.fi
Cc: Adam Klein <adamk@chromium.org>, Ojan Vafai <ojan@chromium.org>, Boris Zbarsky <bzbarsky@mit.edu>, public-webapps@w3.org
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

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
Received on Tuesday, 5 July 2011 16:16:33 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:33 UTC