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

Re: Mutation events replacement

From: Adam Klein <adamk@chromium.org>
Date: Mon, 4 Jul 2011 14:02:32 -0700
Message-ID: <CAEvLGcL0p9fsQtJ6N28iWfLmHMaeTNr+=sWW+qAJyTKxxnOXcA@mail.gmail.com>
To: Olli@pettay.fi
Cc: Ojan Vafai <ojan@chromium.org>, Boris Zbarsky <bzbarsky@mit.edu>, public-webapps@w3.org
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
Received on Tuesday, 5 July 2011 11:56:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:22 UTC