Firefox DOM -- offsetParent vs parentNode

Discussion in 'Javascript' started by amattie@gmail.com, Oct 27, 2006.

  1. Guest

    Anyone know what the specific difference is between the offsetParent
    and parentNode properties of a DOM element are?

    Mozilla's docs on the DOM element
    (http://developer.mozilla.org/en/docs/DOM:element) don't really
    indicate much of a difference, but whatever the difference is is really
    screwing me up in one of my projects. On a specific div node nested
    within a whole bunch of other div nodes in the DOM, the parentNode
    property evaluates to the actual parent node, whereas offsetParent
    evaluates to null. This doesn't really affect me, but when I go to
    clone the node to append it to clone's real parent for another purpose,
    the parentNode of the new clone node remains the actual parent I
    appended it to whereas the offsetParent becomes the HTML body element!
    (Also, just so you know, I checked the parentNode / offsetParent before
    I cloned it to make sure it wasn't a problem with the clone procedure.)

    The reason I need the offsetParent instead of the parentNode is because
    offsetTop for each of my new cloned nodes is screwed up. Because
    offsetParent is the body node, offsetTop gives me the pixel count
    between the top of the browser and the element itself. I need the
    offsetTop of the container element, the _real_ parent node.

    There's nothing really special about this node as far as I can tell.
    I'm using FF 1.5.0.7 and a XHTML 1.0 transitional doctype. I haven't
    tested any other elements on the DOM for this weird behaviour, and I
    haven't tried it in other browsers yet. I've done things similar to
    this before though, and I've never had problems with it. Any ideas of
    how I can fix this problem, or where I can look for more info? Thanks.

    Andrew
    , Oct 27, 2006
    #1
    1. Advertising

  2. wrote:

    > Anyone know what the specific difference is between the offsetParent
    > and parentNode properties of a DOM element are?


    The offsetParent property refers to the nearest positioned (non-static)
    ancestor element. If there is no such element, offsetParent will refer
    to the body element[1].

    Consider the following fragment:

    <body>
    <div>
    <p>Lorum ipsum...</p>
    </div>

    <div style="position: relative;">
    <p>Lorum ipsum...</p>
    </div>
    </body>

    The offsetParent property of the first paragraph will refer to the body
    element. There are no positioned ancestor elements, so that default is
    used. In the second case, the offsetParent property will refer to the
    div element as that is positioned. Here, the div element is the parent,
    but it doesn't have to be.

    > Mozilla's docs on the DOM element
    > (http://developer.mozilla.org/en/docs/DOM:element) don't really
    > indicate much of a difference ...


    That particular document doesn't, but the actual description of the
    property[2] does.

    > On a specific div node nested within a whole bunch of other div nodes
    > in the DOM, the parentNode property evaluates to the actual parent
    > node, whereas offsetParent evaluates to null.


    I can't say I've seen that before. Can you post a link to a small
    demonstration?

    > This doesn't really affect me, but when I go to clone the node to
    > append it to clone's real parent for another purpose, the parentNode
    > of the new clone node remains the actual parent I appended it to
    > whereas the offsetParent becomes the HTML body element!


    Unless there is a positioned ancestor, that should be expected.

    [snip]

    > I'm using FF 1.5.0.7 and a XHTML 1.0 transitional doctype.


    <aside>
    Serving XHTML to clients is typically pointless. Doubly so if the
    Transitional document type is used. The latter should be avoided (if at
    all possible, and it usually is) even for HTML.
    </>

    [snip]

    Mike


    [1] The Mozilla documentation indicates that it should be the
    root element, but this doesn't seem to be the case in
    practice most likely because MSIE uses the body element.
    [2] <http://developer.mozilla.org/en/docs/DOM:element.offsetParent>
    Michael Winter, Oct 27, 2006
    #2
    1. Advertising

  3. Guest

    Well, that solved my problem. I actually had read the wiki pages for
    those properties, but for whatever reason I just ignored the whole
    "relative positioned parent" thing and hadn't even tried what you
    suggested before I posted. I don't remember having to set position:
    relative when I did that before, but I guess I must have.

    Also, after trying that, I found out that my problem with having a null
    offsetParent and the "real" parentNode was that the parent's parent had
    display: none set on it. I removed the display: none later in the
    script before I started cloning nodes and all, but I was erraneously
    eval'ing the parentNode / offsetParent before I set display: block on
    the container element. Therefore, the offsetParent was null and the
    parentNode was the "real" node at that time.

    Anyway, thanks for the help!
    , Oct 27, 2006
    #3
    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. Vittore Zen

    div - position - offsetParent

    Vittore Zen, Nov 4, 2004, in forum: Javascript
    Replies:
    1
    Views:
    120
    Martin Honnen
    Nov 4, 2004
  2. Replies:
    3
    Views:
    213
    Fred Oz
    Jan 13, 2005
  3. webEater

    No offsetParent in Firefox?

    webEater, Dec 19, 2006, in forum: Javascript
    Replies:
    5
    Views:
    101
    webEater
    Dec 21, 2006
  4. Geoffrey Summerhayes

    Firefox offsetParent woes

    Geoffrey Summerhayes, Feb 12, 2008, in forum: Javascript
    Replies:
    7
    Views:
    146
    dhtml
    Feb 13, 2008
  5. Patient Guy
    Replies:
    5
    Views:
    232
    David Mark
    Nov 23, 2008
Loading...

Share This Page