W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: Mutation events replacement

From: Robin Berjon <robin@berjon.com>
Date: Thu, 4 Jun 2009 11:56:08 +0100
Cc: Webapps WG <public-webapps@w3.org>
Message-Id: <D37AA80D-BA63-4969-966B-D2A887471B4E@berjon.com>
To: Jonas Sicking <jonas@sicking.cc>
Hey Jonas,

nice proposal, overall I like it a lot.

On Jun 4, 2009, at 11:07 , Jonas Sicking wrote:
> 'AttributeChanged': Called when an attribute on the node is changed.
> This can be either a attribute addition, removal, or change in value.
> If setAttribute is called the 'AttributeChanged' listener is always
> called, even if the attribute is given the same value as it already
> had. This is because it may be expensive to compare if the old and new
> value was the same, if the value is internally stored in a parsed
> form.

I take it in this case the Attr node is what's passed? Might give a  
reason for its sorry existence :)

> 'ChildlistChanged': Called if one or or mode children are added or
> removed to the node. So for example when innerHTML is set, replacing
> 10 existing nodes with 20 new ones, only one call is made to the
> 'ChildlistChanged' listeners on that node.
> 'SubtreeChanged': Same as 'ChildlistChanged', but called not just for
> children added/removed to the node, but also to any descendants of the
> node.

If multiple nodes are changed at once, I'm guessing you call back with  
a DocumentFragment? For interoperability purposes, this would probably  
require a definition of what a single "DOM operation" is (or we could  
punt and say it's up to the implementation  after all so long as the  
script gets notified of changes everything should work).

I'm thinking we might need ChildElementsChanged and  
ElementsSubtreeChanged that would handle only elements as well.

> 'TextDataChanged': Called when the data in a Text, CDATASection or
> ProcessingInstruction, is changed on the node or any of its
> decendants.

Hmmmmm. If I set the listener on a PI, then I might be interested in  
this event  in which case it should be available on comment nodes  
too. But then again, it seems to imply that I wouldn't get notified of  
changes to the PI's target.

If on the other hand I listen to this on an element, I probably don't  
want to hear about changes made to PIs (or comments) in the subtree.

Robin Berjon - http://berjon.com/
     Feel like hiring me? Go to http://robineko.com/
Received on Thursday, 4 June 2009 10:56:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:54 UTC