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

Re: MutationObserver - a better interface

From: Axel Dahmen <brille1@hotmail.com>
Date: Wed, 12 Feb 2014 02:58:56 +0100
To: www-dom@w3.org
Message-ID: <ldekgm$t7r$1@ger.gmane.org>
Sure, but that's no contradiction to the fact that a MutationObserver is 
always attached to a Node object.

Even if the code you mentioned removes the node from the object tree and 
re-adds it again, it still stays the same Node object. So if the 
MutationObserver interface would have been added to a Node object, all 
references would still be valid and in place.

And please consider the case when a node simply gets removed:

    var myNode = document.getElementById("myNode");

If the MutationObserver interface would have been implemented at the Node 
class, there was a natural correlation between the node and events being 
tracked for children of that node.

My assumption is that every current DOM application implementation 
distinguishes between hard and soft references. When a node is neither 
attached to any document nor referenced by any JavaScript variable it won't 
fire any more mutation events, without doubt.

It doesn't make sense to provide a reference to a separate MutationObserver 
object, being isolated from the Node object it observes. It most easily may 
become orphaned and invalid.

Axel Dahmen

"Anne van Kesteren"  schrieb im Newsbeitrag 

On Tue, Feb 11, 2014 at 6:34 PM, Axel Dahmen <brille1@hotmail.com> wrote:
> But, well, that's, too, even one more point for having had 
> MutationObserver
> being a Node's member as it doesn't make any sense to observe a Node you
> don't have any more references to in code.

As I said you often do keep a reference to the node.

E.g. document.head.appendChild(document.body) will first remove
document.body and then insert it again. It would be bad if the
observer was destroyed while this operation took place as subsequent
document.body.appendChild(...) invocations would go unrecorded.

Received on Wednesday, 12 February 2014 01:59:34 UTC

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