- From: Kartikaya Gupta <lists.webapps@stakface.com>
- Date: Tue, 15 Jul 2008 13:51:41 +0000
- To: Sergey Ilinsky <castonet@yahoo.co.uk>
- Cc: public-webapps@w3.org
On Tue, 15 Jul 2008 12:39:16 +0200, Sergey Ilinsky <castonet@yahoo.co.uk> wrote: > > Specific concerns: > 1) If DOMNodeRemovedFromDocument is fired after the mutation, then in > the listener for this event there is no way to know where Node was > removed from. > (This does not apply to DOMNodeRemoved, since it has a relatedNode > property pointing to node removed) > 2) If DOMNodeRemoved is fired after the mutation, event won't be capable > of bubbling +1. If you make these events fire after the mutation, then they won't go anywhere since the target of the event (the removed node) is free-standing. In order to listen for these events, you'd have to register a listener on every single DOM node, which seems pretty silly. Even if you changed one or both of the events to fire on the parent node, it would still be impossible to determine exactly where the removed node was removed from (i.e. what was the removed node's .nextSibling before it was removed?) The same problem applies to batching up mutations and firing them at the end; there might be operations whose mutation events get discarded because some other mutation happens to the tree before the event is fired. kats
Received on Tuesday, 15 July 2008 13:52:17 UTC