W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: Mutation events replacement

From: Olli Pettay <Olli.Pettay@helsinki.fi>
Date: Sat, 02 Jul 2011 22:18:29 +0300
Message-ID: <4E0F6F05.7030208@helsinki.fi>
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.


  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

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:33 UTC