- From: Sergey Ilinsky <castonet@yahoo.co.uk>
- Date: Tue, 15 Jul 2008 18:18:33 +0200
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- CC: public-webapps@w3.org
Boris Zbarsky wrote: >> 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) > Should DOMNodeRemovedFromDocument have a relatedNode too? A single relatedNode property would not be enough to satisfy developer's curiosity on where exactly node was removed from. > 2) If DOMNodeRemoved is fired after the mutation, event won't be > capable of bubbling > > This is a much more serious issue. To be honest, I think the original > mutation event design was pretty weird. I would have fired the event > on the parent, with the relatedNode being the node being removed or > added... That would avoid this issue. Of course that would be > inconsistent with the way DOMNodeInserted works. Although I do not share negative attitude to the design of Mutation module, I know there are indeed use cases that are not well satisfied with it. The bad part about the potential to changing something in Mutation Module is that it is almost not possible to say "a" there without having to say "b" - the design is very much tight and consistent. > -Boris Sergey Ilinsky/
Received on Tuesday, 15 July 2008 16:19:31 UTC