- From: Andrew Clover <and-w3@doxdesk.com>
- Date: Tue, 6 Jan 2004 22:13:27 +0000
- To: www-dom@w3.org
Curt Arnold <carnold@houston.rr.com> wrote: > Multiple vendors decided that the "following the spec" behavior was not > good thing and took their own approach Can't speak for other implementors, but certainly in my case I didn't deliberately depart from specification: I implemented it in the only way I could see that made sense. (That is, inserting the child in the position it already was - since pxdom doesn't support MutationEvents this is indistinguishable from a no-op.) IMO it takes a really perverse reading of the spec to interpret the "it is first removed" directive as occurring *before* the "existing child node" precondition. I'm not too familiar with Crimson, but I very much suspect its non-atomic behaviour to be an accident rather than something deliberatly coded for. And all this also applies to Node.replaceChild doesn't it? The spec has the same language here. > Since all of these behaviors are reasonable and widely deployed and the > "following the spec behavior" is undesirable, the best that we can do at > this time is warn people not to make that type of call. Certainly for Levels 1 and 2, but surely it would be safe to state insertBefore(child, child) is OK in Level 3 (if there is still time to put it in)? The only implementation we've found with a different opinion is Crimson, which makes no claims to support Core 3.0. As you say, both possibilities are reasonable given the letter of the spec (although IMO the non-atomic one only just barely!) so this would be a tightening of the spec rather than a full change in existing behaviour. -- Andrew Clover mailto:and@doxdesk.com http://www.doxdesk.com/
Received on Tuesday, 6 January 2004 17:35:27 UTC