«

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

"Ken Kast" <> wrote in message
newsNTUa.8790$j%...
>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?

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.

Ken Kast wrote:

> 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?
>
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

Richard Cornford wrote:
> "Ken Kast" <> wrote in message
> newsNTUa.8790$j%...
>
>>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?
>
>
> Absolutely positioned elements are positioned relative to the HTML
> document

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
> 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.
>

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..

> 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.
>
>

"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:
http://www10.brinkster.com/doctorunclear/

"DU" <> wrote in message
news:bg2v7b$1o5$...
<snip>
>>Absolutely positioned elements are positioned relative
>>to the HTML document
>
>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).

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>
>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. ...
<snip>
>So until this issue can be accordingly sorted, cleared,
>there is not a lot that can be said.

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.