Re: node.insertBefore(child, child)

On Mon, 5 Jan 2004, Philippe Le Hegaret wrote:
>>
>> What's the use case for doing what the spec currently says?
>
> The use case for not changing the current behavior without breaking
> existing implementation is simple: as Joe mentioned, this is a DOM Level
> 1 erratum and we don't modifying DOM Level 1 unless a really good
> reason.

The current spec is either poorly defined or defined to do something
undesirable, depending on how one reads it. Isn't that a good enough
reason?


> With your number and an update, we now have 4 implementations doing
> nothing, 3 or 4 considering the case valid (it "works"). The WG is now
> rendering the case "implementation dependent". It is better imho that
> the previous status quo (and will avoid dealing with this case in 2006
> :).

Would it be possible to have it at least partially defined? As a user I
don't mind if mutation events are fired for this case, what concerns me is
the final position of the node and whether an exception is raised.


On Tue, 6 Jan 2004, Curt Arnold wrote:
> 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.

I don't understand why "the best we can do" is not "specify an explicit
useful behaviour" and have non-compliant UAs change to match. As far as
users are concerned, well defined specifications are the most useful.

My proposal would be that the behaviour be that no exception should be
raised, and that the node remain where it is, optionally with the firing
of two mutation events, one for the removal of the node and one for the
reinsertion of the node at the same point.

This would seem to cover the majority (all but one?) of the
implementations mentioned in this thread.

-- 
Ian Hickson                                      )\._.,--....,'``.    fL
U+1047E                                         /,   _.. \   _\  ;`._ ,.
http://index.hixie.ch/                         `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 6 January 2004 16:21:20 UTC