Erik Arvidsson wrote:
The BoxObject for an element works fine in the simple scenario where onlySorry, I don't know what's going on here - I only have a couple of obervations.
the root element has a scrollable overflow. Whenever one or more ancestor
elements has been scrolled the returned box is incorrect and returns the
value that would have been correct when all the scrollable elements had
scrollTop 0.
#e1, #e2 {
overflow: auto;
}
<element id="e1">
...
<element id="e2">
...
<element id="e3">...</element>
...
</element>
...
</element>
var y = document.getBoxObjectFor(document,getElementById("e3")).y
y is only correct if the elements e1 and e2 have not been scrolled.
Is this a known bug? Maybe this is even intentional? Any information
appreciated since the BoxObject seems like the holy grail for finding the
position of an element relative to the document, client viewport and screen.
erik
If I scroll e1, the screenY (since my test only used vertical scrolling) does change. However, it does not change if I scroll e2. This seems totally wrong, since scrolling either changes it's position on the screen.
On a slightly related note, if I scroll the browser window itself, the boxObject.screenY changes for e2 and e3, but not e1!
From what I can see, given one element that's being scrolled (with scrollTop/scrollLeft changing), it's children don't have any changes to their boxObject, but their children (and further children) see their boxObject.screenX/Y change.
I suspect the boxObject.x/y being static is how it's meant to be, but I don't understand why the screenX/Y behaves as it does.
--
James Ross <[EMAIL PROTECTED]>
Webmaster, The University of Warwick Computing Society
http://www.warwickcompsoc.co.uk/
For "luck" like *that* he could go to jail...
-- Yusaku Godai
(Mainson Ikkoku, by Rumiko Takahashi)
