From: Ross on 25 Jan 2010 16:22 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.
From: Ross on 25 Jan 2010 17:00 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.
From: RobG on 25 Jan 2010 19:28 On Jan 26, 8:00 am, Ross <ros...(a)gmail.com> wrote: > 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. -- Rob
From: Thomas 'PointedEars' Lahn on 25 Jan 2010 22:31 RobG wrote: > Ross wrote: >> 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. 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
From: Ross on 26 Jan 2010 10:35 On Jan 25, 7:28 pm, RobG <rg...(a)iinet.net.au> wrote: > On Jan 26, 8:00 am, Ross <ros...(a)gmail.com> wrote: > > > 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. > > -- > Rob 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
|
Next
|
Last
Pages: 1 2 Prev: extend prototype chain? Next: FAQ Topic - What online resources are available? (2010-01-26) |