- From: Doug Schepers <schepers@w3.org>
- Date: Wed, 16 Jul 2008 11:20:58 -0400
- To: public-webapps@w3.org
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