Re: Mutation events replacement

Hi, Jonas-

Thanks, looks interesting!  I'm interested in feedback on this from the 
group, and especially interested in prototypes that test performance.

Also, I note that this proposal doesn't handle computed values, such as 
the result of declarative animation in SMIL/SVG or CSS animation.  Could 
it be extended to deal with that in a performant manner?

Finally, please remember to hold DOM3 Events discussions on www-dom, 
rather than the public-webapps list, for the sanity of the editor.

Regards-
-Doug

---------------
Original Message: Jonas Sicking wrote (on 6/4/09 6:07 AM):
Here's an API that might work:

The following methods are added to the Document, Element and
DocumentFragment interfaces:

   addAttributeChangedListener(NodeDataCallback);
   addSubtreeAttributeChangedListener(NodeDataCallback);
   addChildlistChangedListener(NodeDataCallback);
   addSubtreeChangedListener(NodeDataCallback);
   addTextDataChangedListener(NodeDataCallback);
   removeAttributeChangedListener(NodeDataCallback);
   removeSubtreeAttributeChangedListener(NodeDataCallback);
   removeChildlistChangedListener(NodeDataCallback);
   removeSubtreeChangedListener(NodeDataCallback);
   removeTextDataChangedListener(NodeDataCallback);

And add the following interface:
[CallBack=FunctionOnly, NoInterfaceObject]
interface NodeDataCallback {
  void handleEvent(in Node node);
};

These are *not* DOM-Event listeners. No DOM Events are created, there
are no capture phases or bubbling phases. Instead you register a
listener on the node you are interested in being notified about, and
will get a call after a mutation takes place. The listeners are called
as follows:

'AttributeChanged': Called when an attribute on the node is changed.
This can be either a attribute addition, removal, or change in value.
If setAttribute is called the 'AttributeChanged' listener is always
called, even if the attribute is given the same value as it already
had. This is because it may be expensive to compare if the old and new
value was the same, if the value is internally stored in a parsed
form.

'SubtreeAttributeChanged': As for 'AttributeChanged', but called not
just for attribute changes to the node, but also to any descendants of
the node.

'ChildlistChanged': Called if one or or mode children are added or
removed to the node. So for example when innerHTML is set, replacing
10 existing nodes with 20 new ones, only one call is made to the
'ChildlistChanged' listeners on that node.

'SubtreeChanged': Same as 'ChildlistChanged', but called not just for
children added/removed to the node, but also to any descendants of the
node.

'TextDataChanged': Called when the data in a Text, CDATASection or
ProcessingInstruction, is changed on the node or any of its
decendants.

The exact algorithm would go something like this:

The implementation contains a global list, pendingCallbacks. Each item
in pendingCallbacks is a tuple: <callback, node>.
The implementation also contains a flag, notifyingCallbacks, which
initially is set to false.

If an attribute is changed on node N, perform the following steps:

1. For each 'AttributeChanged' callback, C, registered on N, add an
item to the end of pendingCallbacks with the value <C, N>
2. For each 'SubtreeAttributeChanged' callback, C, registered on N,
add an item to the end of pendingCallbacks with the value <C, N>
3. Set N to N's parentNode.
4. If N is non-null, go to step 2.
5. If notifyingCallbacks is set to true, or pendingCallbacks is empty,
abort these steps.
6. Set notifyingCallbacks to true.
7. Remove the first tuple from pendingCallbacks.
8. Call the handleEvent function on the callback in the tuple, with
the 'node' argument set to the node from the tuple.
9. If pendingCallbacks is not empty, go to step 7.
10 Set notifyingCallbacks to false.

A similar algorithm is run when children are added and/or removed from
an element/document/document-fragment, just replace 'AttributeChanged'
with 'ChildlistChanged', and 'SubtreeAttributeChanged', with
'SubtreeChanged'.

And when Text/CDATASection/ProcessingInstruction nodes have their
contents modified the same algorithm is run, but without step 1, and
with 'SubtreeAttributeChanged' replaced with 'TextDataChanged'.

There's a few of properties here that are desirable, and one that is
sub-optimal.

First of all no notifications are done until after the implementation
is done with the mutations. This significantly simplifies the
implementation since all critical work can be done without worrying
about script performing arbitrary operations in the middle.

Second, all callbacks are notified in the order mutations happen in
the tree, even when another callback performs further mutations. So if
a callback for 'ChildlistChanged' sets a attribute on the newly
inserted node, the other callbacks are still going to get first
notified about the node being inserted, and then about it having an
attribute set. This is thanks to the notifyingCallbacks flag.

Third, these notifications should be significantly faster. Since there
are no DOM Events, there is no need to build propagation chains.
There's also no need to recreated the old attribute value, or to fire
one event for each node if multiple nodes are added and removed.

The only undesirable feature is that code that mutates the DOM from
inside a callback, say by calling setAttribute, can't rely on that by
the time that setAttribute returns, all callbacks have been notified.
This is unfortunately required if we want the second desirable
property listed above.


The only feature of mutation events that this doesn't provide is the
functionality that the
DOMNodeRemovedFromDocument/DOMNodeInsertedIntoDocument. I believe that
these are implemented in some browsers. I don't know how these
browsers would feel about dropping support without supplying some sort
of alternative. If needed we could add the following

   addInDocumentChangedDocumentListener(NodeDataCallback);
   removeInDocumentChangedDocumentListener(NodeDataCallback);

But I'm not sure that there is web-dependency on this, or good use cases.

/ Jonas

Received on Thursday, 4 June 2009 22:44:53 UTC