Re: [D3E] Possible Changes to Mutation Events

Hi, Jonas-

Thanks for this modified proposal.  I want to hear back from those 
who've already commented as to their disposition, and to solicit 
comments from other known implementors (e.g., gtk, BitFlash, Opera, 
JSR), but I think your proposal is reasonable, and well detailed.

A few comments inline...

Jonas Sicking wrote (on 7/17/08 8:51 PM):
> 
> * Add a |readonly attribute long relatedIndex;| property to
>   the MutationEvent interface.
> * Add a DOMChildRemoved event which is fired on a node when one
>   of its children is removed. The relatedNode property contains the
>   removed child, and relatedIndex contains the index the child had
>   immediately before the removal. The event is fired after the removal
>   takes place.
> * Add a DOMDescendantRemovedFromDocument event which is fired on a node
>   when the node is in a document, but any of nodes the descendants is
>   removed from the document. The event is fired after the removal takes
>   place.
>   The relatedNode property contains the removed descendant. The
>   relatedIndex property contains the index the child had
>   immediately before the removal. (Should relatedIndex be -1 when
>   the node wasn't removed from its parent, but rather an ancestor was?)

What is the rationale for having both 'DOMChildRemoved' and 
'DOMDescendantRemovedFromDocument'?  Wouldn't a single one, 
'DOMDescendantRemovedFromDocument' (or, preferably, 
'DOMDescendantRemoved'), work about as well?  You already give a way to 
detect if it was a child or a descendant.

I understand that having the distinction means that you could filter on 
the level of depth to fire events on, but I'm asking if this is useful 
and necessary.


> * Specify *when* the events fire (see details below).

We should do this regardless, since it is tightening up the spec, not 
changing it (though admittedly, it may force some implementations to 
change anyway... but that means more interop).


> * Deprecate the DOMNodeRemoved and DOMNodeRemovedFromDocument events.
>   If this means making them optional or just discouraged I don't really
>   care. I'd even be ok with simply leaving them in as is. Mozilla will
>   simply remove our implementation of the DOMNodeRemoved event. We've
>   never supported the DOMNodeRemovedFromDocument event.

If Mozilla is determined to remove them regardless of what the spec 
says, then I would rather leave them in as specced, but deprecate them. 
  It sounds like we will have alignment from Mozilla and Safari/WebKit, 
and I'm sure that IE would rather implement this simpler version.  I 
imagine that Opera would join in the fun.  Hopefully others would align 
as well.

Then we would have interoperable mutation events in all 4 major desktop 
browsers, decreasing the need for script library compensation.  A script 
lib could still provide DOMNodeRemoved and DOMNodeRemovedFromDocument as 
patches for older code, it seems.


> As for when the events fire (note that this is just clarifications of 
> the spec, not changes to it):
> For events that fire after the mutation takes place I propose that we 
> add a concept of a "compound operation" and state that while compound 
> operations are in progress no mutation events are fired. Instead the 
> events are queued up. After the outermost compound operation finishes, 
> but before it returns control to the caller, the queue of mutation 
> events is processed.

I really like the concept of the "compound operation", and I will add 
that in regardless of other conclusions.  I will specify that a host 
language should indicate when an operation is a "compound operation", 
and describe the precise order of operations.  (See next comment for 
details.)


> A compound operation may itself contain several compound operations. For 
> example parent.replaceChild(newChild, oldChild) can consist of a removal 
> (removing newChild from its old parent) a second removal (removing 
> oldChild from parent) and an insertion (inserting newChild into its new 
> parent). Processing of the queue wouldn't start until after the 
> outermost compound operation finishes.

This actually has at least 3 variant orders of operation (assuming the 
removal of newChild, which may not be in the document at all yet):

* remove newChild, remove oldChild, insert newChild
* remove newChild, insert newChild, remove oldChild
* remove oldChild, remove newChild, insert newChild

All of these are possible, and DOM3 Core doesn't indicate an order.  So 
this adds to the unpredictability of dealing with any compound 
operation, including mutation events.  Requiring a spec to state the 
order would help authors.


> What exactly constitutes a compound operation is left up to the specs 
> that describe the operations. For example setting .innerHTML should 
> likely constitute a compound operation. For DOM Core, every function 
> that mutates the DOM should be considered a compound operation.

Maybe a DOM3 Core 2nd edition, or DOM4 Core, could provide these 
stricter event orders for compound operations.


Regards-
-Doug Schepers
W3C Team Contact, WebApps, SVG, and CDF

Received on Friday, 18 July 2008 05:01:46 UTC