Re: node.insertBefore(child, child)

On Mon, 5 Jan 2004, Philippe Le Hegaret wrote:
>>
>> Is there any code anywhere that depends on Xerces raising an exception?
>
> I don't know.

IMHO this should be an important part of the decision here. :-)


>> Does Xerces really do what the spec says? (i.e. both remove the node and
>> raise an exception.)
>
> It does remove the node and insert it again.

I am confused. What exactly does Xerces do?


> While the spec does say that you should raise an exception if the
> refChild is not in the tree, it doesn't say if you must do the hierarchy
> check _after_ removing the refChild.

The spec says:

# If the newChild is already in the tree, it is first removed.

I interpreted "first" as meaning that was the initial step of the
algorithm.


> > > node.insertBefore(child, child) and node.replaceChild(child, child) are
> > > now described as "implementation dependent" in the specification. It
> > > does not clarify anything except that DOM applications should now be
> > > aware of no interoperability for those cases.
> >
> > That's even less useful than raising an exception! :-)
>
> It does acknowledge the fact that UAs don't follow the specification,
> which is better than nothing imho.

Unfortunately it also prevents implementors from knowing what they should
do. :-)


>> I'd rather the behaviour be well specified and useless than not specified
>> at all (and would much rather it was well specified and useful, especially
>> given the number of interoperable implementations, even if there is one
>> implementation that currently removes the node and raises an exception).
>
> ... as long as the behavior matches your view of interoperable
> implementations,

Given the five UAs mentioned so far -- Mozilla, WinIE, Opera, Safari,
Xerces -- four have the same result, and the fifth (if I understand you)
does something else. You can't claim interoperability if there is only
one implementation. :-) This doesn't have anything to do with my "view".


> but we just demonstrated that at least one implementation does not
> interoperate with the others at the functionality level.

Actually I would be interested in a demonstration, I don't really
understand what Xerces does based on this thread so far.


> True enough, this implementation is not a UA, but it is still a DOM
> implementation that is trying to follow the specification.

I have nothing against server-side libraries being considered just as much
as client-side Web browsers.


> It would be much better if DOM applications were not trying to do
> node.insertBefore(child, child).

There are some algorithms that are neater and simpler if doing that is a
no-op. For example, the algorithm set out in:

   http://www.hixie.ch/specs/html/forms/web-forms#movement

...step 5. Of course it's no big deal as the algorithm can just say "check
that the two nodes aren't the same" first, but that seems inefficient when
one could just rely on the API defining this.

What's the use case for doing what the spec currently says?

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

Received on Monday, 5 January 2004 16:34:01 UTC