W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: Mutation events replacement

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 4 Jun 2009 12:55:13 -0700
Message-ID: <63df84f0906041255k7a844319x99f181d9129f9183@mail.gmail.com>
To: Giovanni Campagna <scampa.giovanni@gmail.com>
Cc: mozer <xmlizer@gmail.com>, Webapps WG <public-webapps@w3.org>
On Thu, Jun 4, 2009 at 6:33 AM, Giovanni Campagna
<scampa.giovanni@gmail.com> wrote:
> What about the simpler:
> void addModificationListener(in DOMString type,in NodeDataCallback
> handler, in boolean subtree);
> void removeModificationListener(in DOMString type,in NodeDataCallback
> handler, in boolean subtree);
> with a string for the modification type (ElementAdded,
> ChildListChanged, ElementRemoved, AnyNodeAdded, etc.), the handler as
> a NodeDataCallback and a boolean indicating if we want to track all
> the subtree or only the current node.
> Possibly, the first argument may be an integer (an enumeration), the
> first function may return an opaque identifier to be used in
> removeModificationListener instead of those three arguments, because
> handler may be lost between addML and removeML, and NodeDataCallback
> may be extended to include a NodeList of nodes involved in the
> modification.

Why would it be easier to keep track of the opaque identifier than to
keep track of the callback. In fact, couldn't you use the callback as
a opac identifier?

> This way we don't have to create a function for every node type (any,
> attribute, element, chardata), multiplied by every node operation
> (add, remove, change), multiplied by 2 (current node only or all
> subtree) and again by 2 (add and remove handler) and thus we
> disambiguate between different dom operations in fast native code,
> rather than in the slow JS interpreter.

I'm not quite following you here. Can you provide an example of a use
case and code pattern that would be problematic?

> Lastly, you could use the event queue mechanism used by HTML5 for
> asynchronous events (modifications callbacks are just events that are
> not captured and neither bubble), instead of defining your own.

I think we want the notifications to fire by the time that the
function that caused the DOM mutation returned. So in code like

myNode.innerHTML = "<b>hello world!</b>";

by the time doStuff is called all the notifactions have fired and
updated whatever state that they need to update.

/ Jonas
Received on Thursday, 4 June 2009 19:56:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:54 UTC