Re: [D3E] Possible Changes to Mutation Events

Maciej Stachowiak wrote:
> 
> 
> On Jul 17, 2008, at 5:51 PM, Jonas Sicking wrote:
> 
>>
>> Doug Schepers wrote:
>>> Jonas proposes two substantive changes to this:
>>> * 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.
>>
>> So based on the feedback so far in this thread, here is a revised 
>> proposal from me, with the added feature that it's backwards compatible
>> with DOM Events Level 2:
>>
>> * 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?)
>> * Specify *when* the events fire (see details below).
>> * 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.
> 
> We'd probably follow suit in WebKit, in which case let's just remove the 
> old events from the spec, or include them as an informative note for 
> implementations that care to be compatible with Level 2.
> 
> However... in practice it seems that many non-browser-hosted 
> implementations of DOM mutation events do not get the ordering right, 
> and for browser-hosted implementations we'll break compatibility anyway, 
> so I do not think there is any value to keeping nominal compatibility in 
> the spec. Thus I would be equally ok with just changing the old events.

The problem is that changing the old events, or at least DOMNodeRemoved 
just doesn't make a whole lot of sense.

If we leave DOMNodeRemoved as is and just change when its fired to be at 
the end of the compound operation, then you are required to add 
listeners to the node itself, rather than something in its parent chain, 
for example the document node. This seems like it would reduce the value 
of the event.

If we change it to be fired on the parent instead of the node, then it 
seems like we are changing the semantics of the event a lot, while 
keeping its name as is. This is likely to break any existing uses of the 
event break really hard, and makes it very possible to write code that 
works across browsers that work the old way and the new way.

/ Jonas

Received on Friday, 18 July 2008 23:11:10 UTC