Re: [D3E] Possible Changes to Mutation Events

Laurens Holst wrote:
> I see, so the motivation for the change request to DOMNodeRemoved is 
> that the second change request (throwing events at the end, after all 
> operations) is be impossible to do if events are not always thrown at 
> the end. And the motivation for throwing events at the end seems to be 
> for a specific kind of optimisation called ‘queuing of events’.

It's not quite an optimization.  At heart, it's a security requirement: 
untrusted script must not be run while data structures are in an 
inconsistent state.

It can be worked around by adding a lot more code to make sure things 
are in a consistent state at all times during, say, a DocumentFragment 
insertion, which is what some implementations have been doing.  But this 
greatly increases complexity and reduces performance of cases that are 
commonly used on the Web (innerHTML).

> By defining that all 
> events have to be fired at the end of the operation, e.g. 
> Document.renameNode can never be implemented by just calling existing 
> DOM operations

This is a serious concern, yes.  On the other hand, that's already the 
case in a lot of situations with the DOM because of the way ranges work. 
  You end up having to call notification-less versions of "basic" methods...

> With regard to the DOMNodeRemoved change request, I do not think these 
> arguments apply. It is doubtful that moving the dispatching of the event 
> to another place will reduce code

I can guarantee you that it would reduce code and improve security in Gecko.

> there is a sensible reason for why some events fire before and some fire after the action

Agreed, but in practice this causes some problems.  If it's possible to 
address the problems while still addressing the mutation event use 
cases, that would be great.

> In our product we have several controls that either access the 
> parentNode property (which would no longer be accessible)

I should note that being able to use parentNode like this assumes that 
you are the only one listening for the mutation event.  That might be a 
good assumption in your project, of course...

> or have an 
> event listener for DOMNodeRemoved on their parent.

Whatever we do, this case certainly needs to work, in my opinion. 
Firing DOMNodeRemoved on the node that actually got removed is not as 
important as this.  Again, in my opinion.

-Boris

Received on Wednesday, 16 July 2008 16:31:15 UTC