- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Sat, 02 Jul 2011 22:18:29 +0300
- To: Dave Raggett <dsr@w3.org>, public-webapps@w3.org
On 07/02/2011 09:27 PM, Dave Raggett wrote: > >> > Olli Pettay >> > Tue, 28 Jun 2011 04:32:14 -0700 >> > These are *not* DOM-Event listeners. No DOM Events are created, there >> > are no capture phases or bubbling phases. Instead you register a >> > listener on the node you are interested in being notified about, and >> > will get a call after a mutation takes place. > > For live concurrent editing of DOM trees, this seems to suggest that you > are required to register an observer with *all* nodes in the DOM tree > and not just its root node. Is that correct? No. You can register listener in the document and get notifications about all the changes in the document tree. The only real functional change comparing to mutation events is handling of element removal. DOMNodeRemoved fires before the node is removed, ChildlistChanged fires after the change has happened. -Olli If correct, it would be a > pain for document editing applications. For use cases like document > editing, it would be valuable to allow observers on ancestor nodes to > see changes to their descendant nodes. > > n.b. the current mutation events work nicely for the document editing > use cases. >
Received on Saturday, 2 July 2011 19:18:54 UTC