Re: node.insertBefore(child, child)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 28 November 2003 6:06 pm, Daniel Glazman wrote:
> Ian Hickson wrote:
> > Does the spec define what should happen with
> >
> >    node.insertBefore(child, child)
> >
> > ...?
> >
> >>From my reading of the spec [1], what should happen is that first the
> >
> > child node should be removed ("If the newChild is already in the tree, it
> > is first removed."), then a "NOT_FOUND_ERR" exception should be thrown,
> > since the node is no longer in the tree and so can't be found.

This is true from my point of view but not really usefull, just as you said.

> > This isn't useful, and isn't what UAs appear to have implemented. Based
> > on this testcase:
> >
> >    http://hixie.ch/tests/adhoc/dom/core/007-demo.html
> >
> > ...Opera, Mozilla, IE6, and Safari all simply ignore the call, not
> > changing the DOM and not raising any exceptions.

Well, a blind spec implemented (damn, just like me) would provide the behavior 
just as the spec acutally specifies, but I now intent to raise a DOMException 
of type HIERARCHY_REQUEST_ERR since this is really a hierarchy request error.

However, ignoring the methods function is really not the best behavior as the 
currently supporting browsers do so :(

> > Could the spec be clarified to specify this interoperable behaviour?
>
> I understand perfectly the reasons behind your proposal but I hate thinking
> of a spec allowing the concept "insert that before itself" without
> complaining about an illegal request. After all, it does not mean "do
> nothing", it really _means_ nothing at all. It's conceptually non-sense.

I propose to clarify this as I said above.

Regards,
Christian Parpart.

- -- 
 22:51:28 up 53 days,  8:48,  3 users,  load average: 0.07, 0.07, 0.03
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/x8U2Ppa2GmDVhK0RAu+nAJ4+Zn/otBDaZjxKiaL2ysG3K3b2/ACeKoGt
sWWo+jfP6XCozWBMRlGSzTA=
=YKPd
-----END PGP SIGNATURE-----

Received on Friday, 28 November 2003 16:59:24 UTC