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

Discussion in 'Javascript' started by Ross, Jan 25, 2010.

  1. Ross

    Ross Guest

    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, Jan 25, 2010
    #1
    1. Advertising

  2. Ross

    Ross Guest

    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.
     
    Ross, Jan 25, 2010
    #2
    1. Advertising

  3. Ross

    RobG Guest

    On Jan 26, 8:00 am, Ross <> 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
     
    RobG, Jan 26, 2010
    #3
  4. 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
     
    Thomas 'PointedEars' Lahn, Jan 26, 2010
    #4
  5. Ross

    Ross Guest

    On Jan 25, 7:28 pm, RobG <> wrote:
    > On Jan 26, 8:00 am, Ross <> 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
     
    Ross, Jan 26, 2010
    #5
  6. Ross

    Ross Guest

    On Jan 25, 10:31 pm, Thomas 'PointedEars' Lahn <>
    wrote:
    > 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



    More good info. Thanks for the insight.

    - Ross.
     
    Ross, Jan 26, 2010
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Joergen Bech
    Replies:
    0
    Views:
    499
    Joergen Bech
    Jun 30, 2005
  2. Replies:
    1
    Views:
    700
  3. Rolf Schroedter

    Accessing large >2GB file succeeds fails with open/read

    Rolf Schroedter, Feb 15, 2005, in forum: C Programming
    Replies:
    6
    Views:
    549
    Olof Lagerkvist
    Feb 16, 2005
  4. Kai Schlamp

    SAX succeeds, but StAX fails

    Kai Schlamp, Mar 6, 2008, in forum: Java
    Replies:
    7
    Views:
    776
    Kai Schlamp
    Mar 12, 2008
  5. Matthew Brett
    Replies:
    4
    Views:
    1,184
    Matthew Brett
    May 9, 2010
Loading...

Share This Page