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

Re: Mutation events replacement

From: Olli Pettay <Olli.Pettay@helsinki.fi>
Date: Thu, 04 Aug 2011 16:38:29 +0300
Message-ID: <4E3AA0D5.7040407@helsinki.fi>
To: public-webapps@w3.org
Hi all,

here is a bit different proposal for mutation events replacement.
This is using the mostly-sync approach, and batching can make it easier
to use with several simultaneous script libraries; each one would use 
their own batch.
For performance reasons it might be useful to have an attribute name
filter for AttrChange, but such thing could be added later.
One advantage this approach has is that it doesn't pollute Node API.


-Olli




interface Modification {
   /**
    * type is either TextChange, ChildListChange or AttrChange.
    * (More types can be added later if needed.)
    */
   readonly attribute DOMString       type;

   /**
    * Target of the change.
    * If an attribute is changed, target is the element,
    * if an element is added or removed, target is the node
    * which was added or removed.
    * If text is changed, target is the CharacterData node which was
    * changed.
    */
   readonly attribute Node            target;
   /**
    * parent node of the target right before the change happened,
    * or null.
    */
   readonly attribute Node            targetParent;
   /**
    * The node which is "batching" the change.
    */
   readonly attribute Node            currentTarget;

   /**
    * The name of the attribute which was changed, or null.
    */
   readonly attribute DOMString       attrName;

   /*
    * The previous value of the attribute or CharacterData node, or null.
    * If a new attribute is added, prevValue is null.
    */
   readonly attribute DOMString       prevValue;

   /*
    * The new value of the attribute or CharacterData node, or null.
    * If an attribute is removed, newValue is null.
    */
   readonly attribute DOMString       newValue;
};

[Callback, NoInterfaceObject]
interface ModificationCallback {
   void handleBatch(in ModificationBatch aBatch);
};

[Constructor(in ModificationCallback aDoneCallback)]
interface ModificationBatch {
   /**
    * Modifications is non-empty array only while aDoneCallback
    * is called. And while that happens, modifications list doesn't
    * change.
    */
   readonly attribute Modification[] modifications;

   void batchTextChanges(in Node aNode);
   void unbatchTextChanges(in Node aNode);

   void batchChildListChanges(in Node aNode);
   void unbatchChildListChanges(in Node aNode);

   void batchAttrChanges(in Node aNode);
   void unbatchAttrChanges(in Node aNode);

   void batchAll();
   void unbatchAll();
};

aDoneCallback is called right before the call which is modifying DOM
returns. If aDoneCallback modifies DOM, new modifications list will be 
collected
and callbacks will be called right after the initial aDoneCallback returns.
ModificationBatches are always handled in the order they are *created*.
Callbacks are never called if modifications list is empty.


Example 1:
// log all the attribute changes
var o = new ModificationBatch(function(b) {
                                 for (var i = 0; i < 
b.modifications.length; ++i) {
                                   var m = b.modifications[i];
                                   if (m.prevValue == null) {
                                     console.log(m.attrName + " added");
                                   } else if (m.newValue == null) {
                                     console.log(m.attrName + " removed");
                                   } else {
                                     console.log(m.attrName + " modified");
                                   }
                                 }
                               }
                             );
o.batchAttrChanges(document);
Received on Thursday, 4 August 2011 13:38:55 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:47 GMT