appendChild that fails in Safari, but succeeds in FF, Camino

[Ross]

Hello all,
I'm having trouble with an appendChild() that works in Firefox and
Camino Browsers, but not in Safari. I"m on Mac OS X with Safari 4.0.4,
Camino 2.0 and Firefox 3.5.

I receive a separate xhtml-xml typed doc ("nuDoc") through an HTTP
GET, and parse it happily, extracting a certain div element. Then I
call the handy little Dom Routine (see below) to append the div
element from nuDoc into one ('pasteHere') in the existing webpage's
DOM. Simply...

alldivs = nuDoc.getElementsByTagName("div");
targetSpot = 'pasteHere'
Dom.add(alldivs[0], targetSpot);

In FF & Camino it works great and I see my two alert pop-ups.
First Alert says
Got these: [object HTMLDivElement] & [object HTMLDivElement]
Then I get Alert with "Progress: Append"

In Safari I get the first alert, with the same objects, so they are
being found, but the script crashes on the appendChild() and I don't
see the second alert.

Earlier in the script I did a successful add of a button using that
same Dom.add, but the button used innerHTML I created on the spot.

var Dom = {
get: function(el) {
if (typeof el === 'string') { //look it up if its a
string
return document.getElementById(el);
} else {
return el; //otherwise just send it
back
}
},
add: function(el, dest) {
var el = this.get(el);
var dest = this.get(dest);
alert("Got these: " + el + " & " + dest);
dest.appendChild(el);
alert("Progress: Append");
},
remove: function(el) {
var el = this.get(el);
el.parentNode.removeChild(el);
}};

Any suggestions?

Thanks
Ross.

 

[Ross]

Solved!

On the idea that perhaps the fragment coming from the other document
might not be easily appendable in a stricter interpretation of DOM, I
looked around for info that might have to do with detaching or
duplicating the element. I found that if I clone the node it works
in Safari then too

So
dest.appendChild(el)

becomes
dest.appendChild(el.cloneNode(true))

Yay. Hope that saves someone else the hour or two I wasted on trying
to figure out why my script worked in one browser and not another.

Ross.

 

[RobG]

Solved!
Maybe.


On the idea that perhaps the fragment coming from the other document
might not be easily appendable in a stricter interpretation of DOM, I
looked around for info that might have to do with detaching or
duplicating the element.   I found that if I clone the node it works
in Safari then too

So
  dest.appendChild(el)

becomes
  dest.appendChild(el.cloneNode(true))

Yay.  Hope that saves someone else the hour or two I wasted on trying
to figure out why my script worked in one browser and not another.

The root issue was probably that you were appending nodes from a XML
document to an HTML document. Is there any reason to expect that
cloning an XML node will *always* produce an HTML node? In all
browsers? You've only tested recent versions of two browsers (Camino
is probably equivalent to Firefox in this case), so you don't know,
the puzzle isn't solved yet.

 

[Thomas 'PointedEars' Lahn]

The root issue was probably that you were appending nodes from a XML
document to an HTML document.

No, the OP's assumptions are correct:

,-<http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-184E7107>
|
| appendChild modified in DOM Level 3
|
| Adds the node newChild to the end of the list of children of this node.
| If the newChild is already in the tree, it is first removed.
|
| Parameters
|
| newChild of type Node
| The node to add.
| If it is a DocumentFragment object, the entire contents of the
| document fragment are moved into the child list of this node
| [...]
| Exceptions
| [...]
| WRONG_DOCUMENT_ERR: Raised if newChild was created from a different
| document than the one that created this node.

Is there any reason to expect that cloning an XML node will *always*
produce an HTML node? In all browsers?

No. Although regarding W3C DOM Level 2+ Core there is no inherent
difference between XML nodes and HTML nodes (both implement the Node
interface) and Node::cloneNode() is described as "a generic copy
constructor for nodes",

dest.appendChild(document.importNode(el, true));

should be used instead which explicitly performs the necessary
transformations regarding namespaces (HTML does not support namespaces,
XML/XHTML does).

<http://www.w3.org/TR/DOM-Level-3-Core/core.html#Core-Document-importNode>


PointedEars

 

[Ross]

The root issue was probably that you were appending nodes from a XML
document to an HTML document. Is there any reason to expect that
cloning an XML node will *always* produce an HTML node? In all
browsers? You've only tested recent versions of two browsers (Camino
is probably equivalent to Firefox in this case), so you don't know,
the puzzle isn't solved yet.

Thanks for the thoughts. First it's xhtml strict not html so I think
that'll be ok.

Yes - this doesn't empirically prove anything across the broad world
of browsers, but it meets my needs in the near term

 

[Ross]

The root issue was probably that you were appending nodes from a XML
document to an HTML document.

No, the OP's assumptions are correct:

,-<http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-184E7107>
|
| appendChild  modified in DOM Level 3
|
|   Adds the node newChild to the end of the list of children of this node.
|   If the newChild is already in the tree, it is first removed.
|
|   Parameters
|
|     newChild of type Node
|       The node to add.
|       If it is a DocumentFragment object, the entire contents of the
|       document fragment are moved into the child list of this node
| [...]
|   Exceptions
| [...]
|     WRONG_DOCUMENT_ERR: Raised if newChild was created from a different
|     document than the one that created this node.

Is there any reason to expect that cloning an XML node will *always*
produce an HTML node? In all browsers?

No.  Although regarding W3C DOM Level 2+ Core there is no inherent
difference between XML nodes and HTML nodes (both implement the Node
interface) and Node::cloneNode() is described as "a generic copy
constructor for nodes",

  dest.appendChild(document.importNode(el, true));

should be used instead which explicitly performs the necessary
transformations regarding namespaces (HTML does not support namespaces,
XML/XHTML does).

<http://www.w3.org/TR/DOM-Level-3-Core/core.html#Core-Document-importNode>

PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

More good info. Thanks for the insight.

- Ross.