Re: Mutation events replacement

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>";
doStuff();

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