W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2014

MutationObserver - a better interface

From: Axel Dahmen <brille1@hotmail.com>
Date: Mon, 3 Feb 2014 18:08:41 +0100
To: www-dom+AEA-w3.org
Message-ID: <lcoiec$4it$1@ger.gmane.org>
I just read through the specification of MutationObserver.

Well, I must admit that I actually don't see the point why MutationObserver 
is a dedicated object, being detached from any node in the document.

The MutationObserver object is ALWAYS attached to a node. Whenever the node 
gets deleted, the MutationObserver becomes obsolete. So why isn't observe() 
just a member function of the Node object, returning the corresponding 
MutationObserver object?


Moreover, I don't understand why the callback function is being set at the 
constructor function of MutationObserver while the observation parameters 
are set at a separate function.

>From my perspective (from OO perspective) it would have made more sense to 
omit the constructor and to add the MutationObserver.observe() member 
function to the Node interface. The callback parameter could have just been 
added to the MutationObserverInit class as an additional property.


That way, using the MutationObserver object would have looked similar to 
this:

   +AHs-
      var observer +AD0- document.getElementById(+ACI-MyNode+ACI-).observe( +AHs-callback: 
myObserveFunc+ADs- childList: true+ADs- attributes: true+ADs- +AH0- )+ADs-

      observer.suspend()+ADs- // pause observation
      observer.continue()+ADs- // continue observation

      observer.takeRecords()+ADs- // pop mutation records
      observer.disconnect()+ADs- // stop observation and invalidate observer 
object
   +AH0-


Is there any reason why this approach has not been taken?

Axel Dahmen 
Received on Monday, 3 February 2014 17:09:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:22 UTC