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

Re: MutationObserver - a better interface

From: Rafael Weinstein <rafaelw@google.com>
Date: Mon, 3 Feb 2014 10:03:05 -0800
Message-ID: <CABMdHiRpgv5h8u6moewetg145nM6ivqtofbHNbLtq+vQUYQzhw@mail.gmail.com>
To: Axel Dahmen <brille1@hotmail.com>
Cc: "www-dom@w3.org" <www-dom@w3.org>
MutationObservers can (and frequently do) observe multiple nodes (and
entire trees of node). The observer is neither conceptually nor concretely
connected to a specific node.


On Mon, Feb 3, 2014 at 9:08 AM, Axel Dahmen <brille1@hotmail.com> wrote:

> 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:
>
>   {
>      var observer = document.getElementById("MyNode").observe( {callback:
> myObserveFunc; childList: true; attributes: true; } );
>
>      observer.suspend(); // pause observation
>      observer.continue(); // continue observation
>
>      observer.takeRecords(); // pop mutation records
>      observer.disconnect(); // stop observation and invalidate observer
> object
>   }
>
>
> Is there any reason why this approach has not been taken?
>
> Axel Dahmen
>
>
>
Received on Monday, 3 February 2014 18:03:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:04 UTC