W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2004

Re: node.insertBefore(child, child)

From: Andrew Clover <and-w3@doxdesk.com>
Date: Tue, 6 Jan 2004 22:13:27 +0000
To: www-dom@w3.org
Message-ID: <20040106221327.GA488@doxdesk.com>

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
Received on Tuesday, 6 January 2004 17:35:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:12 UTC