- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Tue, 15 Jul 2008 11:19:29 -0400
- To: Sergey Ilinsky <castonet@yahoo.co.uk>
- CC: public-webapps@w3.org
Sergey Ilinsky wrote: > 1) Clearly defined use cases seem to be missing from the proposal, would > it be possible to bring them all to the table? It's more a matter of sanity of implementation than anything else, for what it's worth. > 2) The changes contradict with DOM-Level-2 Events where Mutation was > initially defined (back in the year 2000) thus creating backwards > incompatible behavior Yes. The whole proposal is to change the Events specification. > 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? > 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. -Boris
Received on Tuesday, 15 July 2008 15:20:11 UTC