Relative Absolute Position

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Ken Kast

    Relative Absolute Position

    Here's my situation. I have a statically positioned table that has an image
    in a cell. I also have some layers, defined by absolute-positioned DIVs for
    some animation. Everything works until I scroll/resize. Then the image
    "moves" on the screen but the animation doesn't. The net effect is that
    their relative positioning changes. I'd like to have it be that they would
    stay in the same relative position. I want to keep the image as an element
    in the table and not make it a background so that I can use it's position
    for other script activities, and because the table keeps other elements in
    relative position.

    Any recommendations on how I handle this?

    Thanks.

    Ken


  • Richard Cornford

    #2
    Re: Relative Absolute Position

    "Ken Kast" <ken@NOSPAMkenk ast.com> wrote in message
    news:PNTUa.8790 $j%4.386272@twi ster.socal.rr.c om...[color=blue]
    >Here's my situation. I have a statically positioned table
    >that has an image in a cell. I also have some layers,
    >defined by absolute-positioned DIVs for some animation.
    >Everything works until I scroll/resize. Then the image
    >"moves" on the screen but the animation doesn't. The
    >net effect is that their relative positioning changes.
    >I'd like to have it be that they would stay in the same
    >relative position. I want to keep the image as an element
    >in the table and not make it a background so that I can use
    >it's position for other script activities, and because the
    >table keeps other elements in relative position.
    >
    > Any recommendations on how I handle this?[/color]

    Absolutely positioned elements are positioned relative to the HTML
    document so they should scroll with the rest of the document. If they
    are keeping their position relative to the vewport's upper left corner
    during scrolling then your animation script must be re-positioning them.
    In which case it is handling scrolling inappropriately and needs to be
    corrected.

    Correcting for changes in page layout due to window re-sizing means
    either constantly checking the page offset of the image element and
    using that as a basis for positioning the positioned elements, or doing
    the same in response to window.onresize events. Unfortunately,
    window.onresize is not supported by some of the browsers that would
    otherwise be happy with the other features of your script as described.

    In any event, you are unlikely to receive any more useful suggestions
    unless you provide access to a working example of the script in action.

    Richard.


    Comment

    • Dom Leonard

      #3
      Re: Relative Absolute Position

      Ken Kast wrote:
      [color=blue]
      > Here's my situation. I have a statically positioned table that has an image
      > in a cell. I also have some layers, defined by absolute-positioned DIVs for
      > some animation. Everything works until I scroll/resize. Then the image
      > "moves" on the screen but the animation doesn't. The net effect is that
      > their relative positioning changes. I'd like to have it be that they would
      > stay in the same relative position. I want to keep the image as an element
      > in the table and not make it a background so that I can use it's position
      > for other script activities, and because the table keeps other elements in
      > relative position.
      >
      > Any recommendations on how I handle this?
      >[/color]
      I assume when you say scroll/resize you mean the document is reflowed:
      the table element moves its page coordinates on account of the reflow,
      but the absolutely positioned element doesn't because it uses page
      coordintates in the first place. That much is to be expected.

      What is not spelled out in as many words in the CSS spec is that real
      world browsers take top and left values for positioning with respect to
      the next outer positioned element - I will ignore "auto" positioning.

      Suggest you try filling the table cell with a relative positioned
      element, put the image inside it as a static element, and also put the
      animation absolutely positioned elements inside the relative container,
      supplying top and left values with respect to it.

      There is now a small chance it will work, without saying how good a
      chance. It is more likely to work in Opera or Mozilla than IE. If
      needed, the chances of correctly interogating the position of a static
      element within a relative element under IE are quite low.

      The other way is to put an onresize event handler in to recalculate and
      move the absolutely positioned animation divs for you.

      HTH
      Dom




      Comment

      • DU

        #4
        Re: Relative Absolute Position

        Richard Cornford wrote:[color=blue]
        > "Ken Kast" <ken@NOSPAMkenk ast.com> wrote in message
        > news:PNTUa.8790 $j%4.386272@twi ster.socal.rr.c om...
        >[color=green]
        >>Here's my situation. I have a statically positioned table
        >>that has an image in a cell. I also have some layers,
        >>defined by absolute-positioned DIVs for some animation.
        >>Everything works until I scroll/resize. Then the image
        >>"moves" on the screen but the animation doesn't. The
        >>net effect is that their relative positioning changes.
        >>I'd like to have it be that they would stay in the same
        >>relative position. I want to keep the image as an element
        >>in the table and not make it a background so that I can use
        >>it's position for other script activities, and because the
        >>table keeps other elements in relative position.
        >>
        >>Any recommendations on how I handle this?[/color]
        >
        >
        > Absolutely positioned elements are positioned relative to the HTML
        > document[/color]

        Absolutely positioned elements are positioned relative to the
        containing block (aka offsetParent node).

        so they should scroll with the rest of the document.

        Absolutely positioned elements do not "scroll with" the rest of the
        document: they are just absolutely positioned, "nailed" within their
        respective offsetParent nodes (or containing block, if you wish).

        If they[color=blue]
        > are keeping their position relative to the vewport's upper left corner
        > during scrolling then your animation script must be re-positioning them.
        > In which case it is handling scrolling inappropriately and needs to be
        > corrected.
        >[/color]

        When I first read the OP, I just thought there were no concrete details,
        no url, no specifics (browser, version, page rendering mode,etc),
        nothing reliable, no sufficient chunks of relevant code (not even a
        single line) to be able to say anything. The page where this problem
        happens could be 3000 lines of code long or 100 lines long. Who knows?
        The problem could be just CSS and markup but the post was made in 2
        scripting language newsgroups, so..
        [color=blue]
        > Correcting for changes in page layout due to window re-sizing means
        > either constantly checking the page offset of the image element and
        > using that as a basis for positioning the positioned elements, or doing
        > the same in response to window.onresize events. Unfortunately,
        > window.onresize is not supported by some of the browsers that would
        > otherwise be happy with the other features of your script as described.
        >
        > In any event, you are unlikely to receive any more useful suggestions
        > unless you provide access to a working example of the script in action.
        >
        > Richard.
        >
        >[/color]

        "Could", "maybe", "if", etc... When a webpage difficulty description is
        highly visual and seems obviously complex, involving many graphical
        elements interacting (I counted at least 4 elements in his description)
        in the layout, then you need to see the code.

        A majority of people asking for help in web programming newsgroups
        don't author valid/validated markup code, rely on table design, use a
        lot of amateur script functions taken here and there in copy-N-paste
        javascript sites, resort to all kinds of hacks (eval, document.write,
        setInterval, etc..), are only interested in results being visible on
        their browser and their machine regardless of implications on users'
        systems, etc...

        So until this issue can be accordingly sorted, cleared, there is not a
        lot that can be said.

        DU
        --
        Javascript and Browser bugs:


        Comment

        • Richard Cornford

          #5
          Re: Relative Absolute Position

          "DU" <drunclear@hotR EMOVEmail.com> wrote in message
          news:bg2v7b$1o5 $1@news.eusc.in ter.net...
          <snip>[color=blue][color=green]
          >>Absolutely positioned elements are positioned relative
          >>to the HTML document[/color]
          >
          >Absolutely positioned elements are positioned relative
          >to the containing block (aka offsetParent node).
          >[color=green]
          >>so they should scroll with the rest of the document.[/color]
          >
          >Absolutely positioned elements do not "scroll with" the
          >rest of the document: they are just absolutely positioned,
          >"nailed" within their respective offsetParent nodes (or
          >containing block, if you wish).[/color]

          Yes, I was being excessively vague. Though it remains the case that if
          the offsetParent node scrolls with the page and its absolutely
          positioned descendants do not go with it, something active has been, or
          is being, done to prevent them.

          <snip>[color=blue]
          >When I first read the OP, I just thought there were no
          >concrete details, no url, no specifics (browser, version,
          >page rendering mode,etc), nothing reliable, no sufficient
          >chunks of relevant code (not even a single line) to be able
          >to say anything. ...[/color]
          <snip>[color=blue]
          >So until this issue can be accordingly sorted, cleared,
          >there is not a lot that can be said.[/color]

          Agreed. And someone who does not understand enough about browser
          scripting to see that nothing useful can be said about the undesired
          behaviour of a script without the commenters being able to see the
          script is unlikely to be able to do anything with any vague speculations
          and guesswork that they do receive. Leaving my earlier comments serving
          no purpose but to underline the importance of the "Show the ******
          script" remark I ended with.

          Richard.


          Comment

          Working...