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
