- From: Rafael Weinstein <rafaelw@google.com>
- Date: Mon, 3 Feb 2014 10:03:05 -0800
- To: Axel Dahmen <brille1@hotmail.com>
- Cc: "www-dom@w3.org" <www-dom@w3.org>
- Message-ID: <CABMdHiRpgv5h8u6moewetg145nM6ivqtofbHNbLtq+vQUYQzhw@mail.gmail.com>
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