- 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