Re: [D3E] Possible Changes to Mutation Events

Hi, Grauw-

First, I want to note that I'm just collecting data here... I can see 
both sides of the argument on this particular issue, so as editor, I'm 
happy to specify this however it seems most beneficial to authors and 
implementors (in that order).  I appreciate all the good feedback 
everyone is supplying.

I realize that by relaying and summarizing Jonas' and Maciej's request, 
I may seem to have already aligned myself with a "side" here, but any 
defense I'm making is as an advocate for the authors and for the devil 
(not necessarily in that order).

So, I will leave it up to Jonas and Maciej to present counter-arguments.

Just a couple comments inline...

Laurens Holst wrote (on 7/16/08 9:36 AM):
>
> To expand a little more on item 3; I do not think the ‘consistency’ 
> argument really applies here, because there are plenty of events that 
> fire before the actual action takes place (e.g. all cancelable events). 
> Now of all 7 mutation events, only two are fired before the action, so 
> it is true the majority of events fires after. However they do this 
> because it makes sense for their specific operations, not because of 
> some unwritten rule that events always have to be fired after the action.

The consistency and predictability I was referring to was not alignment 
with the other mutation events firing after the operation, but rather with:

a) The bit in DOM3 Events that says, "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."

b) predictability that operations will not end up with surprising 
results regarding the tree structure as a result of complex operations.

> By the way, note that Backbase is also looking at this from an 
> implementor’s point of view :).

Yes, it seems Backbase would be considered both an implementor and an 
author (that is, you implement the functionality of the spec, and 
provide content on top of that functionality).  It would be interesting 
so see an examination of the different needs and markets for desktop 
browser vendors, mobile browser vendors, and script library vendors, 
with regards to reliance on underlying platforms and ability to push 
changes out into deployed code.

I took a look through the Backbase demo... very impressive stuff.  Much 
of it was even accessible and navigable by keyboard control, which was 
even nicer.


>> 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.
> 
> The differences are pretty big, you shouldn’t downplay them as being 
> ‘details’. I’m sure things will break. I think this is a very bad idea.

I didn't mean "details" in a pejorative sense, but rather as a contrast 
to a more drastic change, such as removing mutation events altogether. 
The point was that certain aspects of the events could possibly be 
changed without affecting existing applications or script code; you have 
evidence that this is not the case here, but without knowing the details 
of that, it was hard to judge.  The devil is in the details, after 
all... and specifications are, let's face is, all about details.


> It is certain.
> 
> Some examples of what would break in our product:

Okay, thanks for the details, especially regarding what remedial steps 
you'd have to take.


> I disagree with your suggestion that the event as it is currently 
> specified would be “difficult to implement” or “unpredictable to use”. 

I was really trying to characterize Jonas' stance, and may not have been 
successful at it.  I invite him to provide more details.


> I do not care so much about backwards compatibility with earlier 
> revisions of the DOM level 3 spec (although I hope there won’t be really 
> big changes :)), however this concerns compatibility with DOM level 2 
> which has been a REC since 2000. As far as I know (and if Appendix B: 
> Changes is not omitting anything), DOM level 3 has so far not introduced 
> any backwards incompatibilities with DOM level 2. Doing this would set a 
> very bad precedent.

None of the other changes currently being considered would affect 
compatibility with DOM2... most of them have to do with Key Identifiers 
and IMEs, new events (e.g. wheel, mousewheel, dblclick), event order, 
and default actions (off the top of my head).  I'm glad that you are 
paying attention, and look forward to your feedback on these other 
issues, too.


> I think you should be very, very reluctant to break backwards 
> compatibility with an 8-year old REC. The DOM specifications are a core 
> part of XML technologies, and if those standardised core technologies 
> can not be trusted to be compatible with previous Recommendations, 
> requiring application-level changes, maybe XML technologies aren’t as 
> reliable as we all thought.

Well, there are those who would argue that anyone, but I'm not one of 
them. :)

Your point about compatibility with DOM2 is very well made and taken.

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

Received on Wednesday, 16 July 2008 15:21:33 UTC