Re: node.insertBefore(child, child)

Andrew Clover wrote:

>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.
>  
>
That more elegantly states what I was trying to say.  A strictly literal 
interpretation of the description resulted in undesirable behavior.  
Most implementations reasoned that a no-op was best, Oracle thought that 
throwing a HIERARCHY_REQUEST_ERR was best and Crimson didn't identify 
the issue and did the remove followed by throwing a NOT_FOUND_ERR.  The 
apparent intent of the order of steps was to describe the order of 
mutation events and not prescribe the details of the implementation.


>And all this also applies to Node.replaceChild doesn't it? The spec has the
>same language here.
>
>  
>
That was caught and the resolution also applied to it.

>>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.
>  
>
I don't think anyone would reject an errata because it declared 
Crimson's behavior non-conformant since it is obviously undesirable.  
Throwing a HIERARCHY_REQUEST_ERR is probably the very best thing to do 
since a call to node.insertBefore(child, child) would strongly suggest a 
coding error.  However, that is not what the browser vendors did.  The 
current wording allows the implementer a choice, either throw an 
exception if you are most concerned about identifying bugs and program 
correctness or do a no-op if you are concerned with compatibility with 
the currently deployed user agents.

I agree with the WG resolution and can identify scores of other issues 
that are more significant to end users than continuing to beat up this 
issue.  Fixing up the holes in the L3 drafts before they become specs is 
a much better use of time than trying to trying to tweak the behavior 
for an abnormal scenario in a spec that is 6 or so years old.

>  
>

Received on Tuesday, 6 January 2004 18:27:58 UTC