Re: [D3E] Possible Changes to Mutation Events

Hi, Sergey-

Thanks for your prompt and informative feedback!

Sergey Ilinsky wrote (on 7/15/08 6:39 AM):
> 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?

That's a reasonable request

I think that Jonas and Maciej described some of the use cases (from an 
implementor's point of view) in their discussion:
* optimizing based on queuing of events
* reduction of code
* consistency and predictability of behavior
* interoperability on the issue of when the events fire (currently the 
spec says, "Many single modifications of the tree can cause multiple 
mutation events to be dispatched. Rather than attempt to specify the 
ordering of mutation events due to every possible modification of the 
tree, the ordering of these events is left to the implementation." [1])

It would be nice to have more use case outlined.

This knife cuts both ways, of course.  Can you cite some cases 
(preferably in use today) that rely on keeping things the way they are?


> 2) The changes contradict with DOM-Level-2 Events where Mutation was 
> initially defined (back in the year 2000) thus creating backwards 
> incompatible behavior

Not necessarily.  It has the potential to create 
backwards-incompatibility, but only if there are scripts and 
implementations that rely on the specific details that are proposed for 
change, i.e. that depend on the DOMNodeRemoved and 
DOMNodeRemovedFromDocument events firing before removal.  If the script 
only relies on knowing that a node was removed, and doesn't care much 
when, then it's not actually a problem.


> 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 don't believe that is correct.  DOM3 Event states:

"At the beginning of the dispatch, implementations must first determine 
the event object's propagation path. This is an ordered list of event 
targets the object may propagate to. The last item in the list is the 
event's target; the preceding items in the list are referred to as the 
target's ancestors and the immediately preceding item as the target's 
parent. Once determined, the propagation path cannot be changed. As an 
example, in the DOM event flow event listeners might change the position 
of the target node in the document while the event object is being 
dispatched; such changes do not affect the propagation path." [2]

You could simply add another event listener on the target element's 
parent (or other relevant ancestor) to find the tree context, if necessary.

A use case demonstrating that this wouldn't suffice would weigh in favor 
of not changing it.


> (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))

Are you certain about that?  I don't want stuff to break (especially in 
an irreparable way), but neither do I want to forestall making a change 
to the spec that would be easier to implement and more predictable to 
use, based on supposition of problems.  It would be very useful if you 
could point out what would break, and how.


> 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.

Can you please confirm that the behavior your implementation relies on 
would actually be negatively affected by the particular changes 
detailed?  Please consider that this may actually have a positive impact 
on your implementation's performance and maintainability.  Detailed 
comments would be helpful.

I will note that other changes are also being made to the specification, 
and while we are trying to be as "backwards compatible" with earlier 
revisions of the spec as possible, we also place a high priority on the 
spec meeting its use cases and requirements.  I'm sensitive that this 
spec is too long in being finished, and that implementations reasonably 
have relied on it despite its status, but it's a balancing act.

[1] 
http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-eventgroupings-mutationevents
[2] http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-flow

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

Received on Tuesday, 15 July 2008 21:31:03 UTC