Absolute position of a relative element

[Stephan Koser]

Hi,

how can I get the absolute position of a relative element?

We dynamically create a page with multiple segments which are relatively
ordered among each other. In these segments we have input fields.
When such an input field is focused I need it's absolute position.
Is there a way to do so with IE > 6?

thanks...

bye Stephan...

[Andrew Thompson]

On Mon, 14 Jun 2004 17:20:57 +0200, Stephan Koser wrote:
....

Is there a way to do so with IE > 6?

That would be IE 7, IE 8,.. would it? ;-)

--
Andrew Thompson
http://www.PhySci.org/ Open-source software suite
http://www.PhySci.org/codes/ Web & IT Help
http://www.1point1C.org/ Science & Technology

[Stephan Koser]

"Andrew Thompson" <Se********@www .invalid> schrieb im Newsbeitrag
news:1r******** *************** ******@40tude.n et...

On Mon, 14 Jun 2004 17:20:57 +0200, Stephan Koser wrote:
...

Is there a way to do so with IE > 6?

That would be IE 7, IE 8,.. would it? ;-)

Oh, sorry - that's completely wrong. I mean: IE >= 5 !

bye...

[Mike Foster]

On Mon, 14 Jun 2004 17:20:57 +0200, Stephan Koser <sk****@web.d e> wrote:

Hi,

how can I get the absolute position of a relative element?

We dynamically create a page with multiple segments which are relatively
ordered among each other. In these segments we have input fields.
When such an input field is focused I need it's absolute position.
Is there a way to do so with IE > 6?

thanks...

bye Stephan...

Hi Stephan,

This is from the X Library (http://cross-browser.com/). You don't have to use the library, but this should give you some ideas. Two library functions are not provided here: xDef() returns true if all it's arguments are 'defined'; xGetElementById () works as you would expect.

function xPageX(e) {
if (!(e=xGetElemen tById(e))) return 0;
var x = 0;
while (e) {
if (xDef(e.offsetL eft)) x += e.offsetLeft;
e = xDef(e.offsetPa rent) ? e.offsetParent : null;
}
return x;
}
function xPageY(e) {
if (!(e=xGetElemen tById(e))) return 0;
var y = 0;
while (e) {
if (xDef(e.offsetT op)) y += e.offsetTop;
e = xDef(e.offsetPa rent) ? e.offsetParent : null;
}
return y;
}

[Richard Cornford]

Mike Foster wrote:
<snip>

function xPageX(e) {
if (!(e=xGetElemen tById(e))) return 0;
var x = 0;
while (e) {
if (xDef(e.offsetL eft)) x += e.offsetLeft;
e = xDef(e.offsetPa rent) ? e.offsetParent : null;
}
return x;
}
function xPageY(e) {
if (!(e=xGetElemen tById(e))) return 0;
var y = 0;
while (e) {
if (xDef(e.offsetT op)) y += e.offsetTop;
e = xDef(e.offsetPa rent) ? e.offsetParent : null;
}
return y;
}

As an observation, there are two other considerations in calculating the
position of elements on a page. Borders around elements and elements
within other elements with scrolling overflow that are partially
scrolled. Borders can be coped with either using clientTop/Left or
getting top and left border px dimensions from a calculated style
object, on more recent browsers.

Scrolling on containing elements can be addressed with scrollTop/Left,
where supported, but Opera 7 makes it a pain to attempt that with inline
elements.

In the vast majority of contexts neither of these additional factors
will apply.

Richard.

[Richard Cornford]

Mike Foster wrote:
<snip>

function xPageX(e) {
if (!(e=xGetElemen tById(e))) return 0;

<snip> ^

I forgot to mention; wouldn't returning NaN at that point be a better
indicator of failure, as it is always possible that the referenced
element actually is 0px offset into the page.

Richard.

[Mike Foster]

On Tue, 15 Jun 2004 21:03:51 +0100, Richard Cornford <Ri*****@litote s.demon.co.uk> wrote:

Mike Foster wrote:
<snip>

function xPageX(e) {
if (!(e=xGetElemen tById(e))) return 0;

<snip> ^

I forgot to mention; wouldn't returning NaN at that point be a better
indicator of failure, as it is always possible that the referenced
element actually is 0px offset into the page.

Richard.

You're assuming that Javascript programmers actually validate return values - even C programmers don't do that as much as that should ;-) Yes, technically it should return an error code not in the function domain and your suggestion (NaN) fits the bill perfectly. Actually I have many functions which don't return an error code - my reasoning then, as I remember it, was that the functions would be more likely to fail gracefully this way. You have a good point tho and I'm not so sure my original idea worked as well as I thought it might. This just hasn't come up in quite a while :-) I hesitate to make indiscriminate changes because many people are using the core functions. Still, its a good idea so I may have to put this on the to-do list ;-)

Thanks!
Mike

[Richard Cornford]

Mike Foster wrote:

Richard Cornford wrote: <snip> You're assuming that Javascript programmers actually validate return
values - even C programmers don't do that as much as that should ;-)
I would be being very short-sighted if I assumed any such thing. The
unfortunate reality is the vast majority of the people authoring
javascript are not programmers, don't really understand what they are
doing and do not apply any standards to what they produce (or even
aspire to). But that is not a good reason for making it difficult for
those that do.

In reality javascript programmers (at least those working with web
browsers) have more reason for being defensive and cautions than C
programmers do. A C program in an equivalent context, interacting with a
DOM, could be written with a fair confidence about the DOM
implementation. At minimum it could expect to only have to work with one
implementation at a time, and that implementation would be known.

Browser scripts are written to be sent out to unknown browser software
where they realistically should expect to find numerous more or less
divergent DOM implementations . Script failure is a consequence so
inevitable in that context that its controlled handling should be
written into the script, and that means checking to see when it can be
predicted, is happening or has happened.

Learning how to do that efficiently is a major part of learning to be
good at browser scripting. for example, if your function returned NaN on
the first call it could reasonably be assumed that it would continue to
do so. There would be no point calling it again. While a non-NaN numeric
return value on the first call would be grounds to assume that all
subsequent calls will also returned non-NaN values (subject to the
element not being removed from the DOM by the script). Testing that you
have a position reporting facility before its use is vital but, once
checked, testing all subsequent returned values would needlessly slow
the script down.

<snip> ... , was that the functions would be more likely
to fail gracefully this way.
It is really the code employing the functions that should be failing
gracefully, as it is the code that would be written with a knowledge of
what was appropriate as a response to failure in its context.

<snip> ... . I hesitate to make indiscriminate
changes because many people are using the core functions. ...

<snip>

Yes, you can be certain that if you change the behaviour of an API, even
objectively for the better, then some of the code written to use
previous versions it will promptly fail.

Richard.

[Mike Foster]

Richard Cornford said:

Mike Foster wrote:

You're assuming that Javascript programmers actually validate return
values - even C programmers don't do that as much as they should ;-)
I would be being very short-sighted if I assumed any such thing. The
unfortunate reality is the vast majority of the people authoring
javascript are not programmers, don't really understand what they are
doing and do not apply any standards to what they produce (or even
aspire to). ...

LOL! I was a C programmer long before I started this Javascript hobby. That
influences my perspectives. I usually refer to scripters as "programmer s"
as a sign of coder respect and camaraderie, and to inspire them to "aspire
to apply standards to what they produce", and to raise the overall
respectability of their craft and industry. Neverthless I do recognize that
many scripters are web designers who are forced to use scripting - and they
don't really want to get too deep into it.

Richard Cornford said: But that is not a good reason for making it difficult for those that do.
Point well taken. I'm sure I will eventually implement your suggestion.
While we're on this topic I'd be grateful for anyone's thoughts on appropriate
error codes to return from other functions. Looking thru my functions I see
3 different data types returned: Number, String and Element.

1. If a function normally returns a number I will return NaN as an error code.

2. If a function normally returns a string, as an error code should it return
null instead of returning an empty string?

3. If a function normally returns an element reference is it appropriate to
return null as an error code? (I think this one is right)
... Testing that you
have a position reporting facility before its use is vital but, once
checked, testing all subsequent returned values would needlessly slow
the script down.

I agree. When I post little demos for people I usually assume that such checks
will be done eariler. Still, these functions are not representative of most of
my 'core' functions which test for object existence before using the object.
Correcting this is also a task now going on my to-do list ;-)

Thanks for your replies,
Mike

[Richard Cornford]

Mike Foster wrote:

Richard Cornford said: <snip> ... . Neverthless I do recognize that many scripters are web
designers who are forced to use scripting - and they don't
really want to get too deep into it.
Forced to? Someone is holding a gun to their head? Want to use scripting
certainly, need to be able to offer scripting it in order to compete in
their chosen profession, probably, but I don't see how they could be
"forced to" use scripting.

Unfortunately a combination of a desire to program one of the most
unreliable and inconsistent software environments that exists (the web
browser), and an unwillingness to learn programming at all, is not
likely to results in a successful outcome. And a quick sample of
Internet browser scripts would rapidly reveal how spectacularly
unsuccessful that outcome can be.

<snip> 2. If a function normally returns a string, as an error code should
it return null instead of returning an empty string?
Strings can be a bit of a problem as an empty string is a reasonable
error when a string of data (so non-empty) marks success, and easy to
test by type-converting it to boolean. Returning null is probably the
only sensible option when an empty string could be a meaningful results,
and all strings are != null.
3. If a function normally returns an element reference is it
appropriate to return null as an error code? (I think this one is
right)

That would be my choice, and consistent with return values from
unsuccessful W3C DOM element retrieval methods

... Testing that you have a position reporting facility before
its use is vital but, once checked, testing all subsequent
returned values would needlessly slow the script down.

I agree. When I post little demos for people I usually assume that
such checks will be done eariler.

<snip>

That is always a dilemma because someone seeing a facility employed
without the required associated testing may take it as indication that
doing so is acceptable. While an example that wraps the required testing
directly around the use of the facility being demonstrated (and repeats
those tests for each subsequent use) might be taken as a guide to
implementation, even though that is rarely an efficient style of
implementation. And a full optimal implementation would be a ludicrous
thing to write just to demonstrate the use of one facility for a Usenet
post.

Richard.