Re: [D3E] Possible Changes to Mutation Events

Doug Schepers wrote:
> * DOMNodeRemoved and DOMNodeRemovedFromDocument would be fired after 
> the mutation rather than before
> * DOM operations that perform multiple sub-operations (such as moving 
> an element) would be dispatched (in order of operation) after all the 
> sub-operations are complete.
General concerns:
1) Clearly defined use cases seem to be missing from the proposal, would 
it be possible to bring them all to the table?
2) The changes contradict with DOM-Level-2 Events where Mutation was 
initially defined (back in the year 2000) thus creating backwards 
incompatible behavior

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

(I did not yet dig into any specific functionality that depends on the 
present behavior (and potential change) of the events in subject (for 
sure lots of stuff would break))

Tech Lead at Backbase,
Sergey Ilinsky/

P.S. Backbase Ajax Framework contains an implementation of DOM-Events 
(Level-3) module (as well as other DOM modules) and it is dependent on 
the present behavior.

Received on Tuesday, 15 July 2008 10:56:29 UTC