Absolute position of a relative element

Discussion in 'Javascript' started by Stephan Koser, Jun 14, 2004.

  1. 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...
     
    Stephan Koser, Jun 14, 2004
    #1
    1. Advertising

  2. "Andrew Thompson" <> schrieb im Newsbeitrag
    news:1rlag6yhd3s8a$...
    > 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...
     
    Stephan Koser, Jun 14, 2004
    #2
    1. Advertising

  3. Mike Foster wrote:
    <snip>
    > function xPageX(e) {
    > if (!(e=xGetElementById(e))) return 0;
    > var x = 0;
    > while (e) {
    > if (xDef(e.offsetLeft)) x += e.offsetLeft;
    > e = xDef(e.offsetParent) ? e.offsetParent : null;
    > }
    > return x;
    > }
    > function xPageY(e) {
    > if (!(e=xGetElementById(e))) return 0;
    > var y = 0;
    > while (e) {
    > if (xDef(e.offsetTop)) y += e.offsetTop;
    > e = xDef(e.offsetParent) ? 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, Jun 15, 2004
    #3
  4. Mike Foster wrote:
    <snip>
    > function xPageX(e) {
    > if (!(e=xGetElementById(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.
     
    Richard Cornford, Jun 15, 2004
    #4
  5. 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.
     
    Richard Cornford, Jun 16, 2004
    #5
  6. Stephan Koser

    Mike Foster Guest

    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 "programmers"
    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
     
    Mike Foster, Jun 17, 2004
    #6
  7. 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.
     
    Richard Cornford, Jun 17, 2004
    #7
  8. Stephan Koser

    Mike Foster Guest

    Richard Cornford said:
    > Mike Foster wrote:
    >> ... . 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.
    > ...


    'Forced' was a bad choice of words, eh ;-)

    Richard Cornford said:
    > Mike Foster wrote:
    >> 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.
    > ...


    I think I like the idea of returning null for these functions.

    Richard Cornford said:
    > Mike Foster wrote:
    >>> ... 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.
    >


    Indeed!

    Thanks for your time,
    Mike
     
    Mike Foster, Jun 18, 2004
    #8
    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. Luqman
    Replies:
    1
    Views:
    679
    Luqman
    Feb 7, 2006
  2. Rob Stampfli
    Replies:
    1
    Views:
    448
    Spartanicus
    May 17, 2006
  3. Microsoft Newsserver

    page element - absolute position

    Microsoft Newsserver, Apr 18, 2008, in forum: ASP .Net
    Replies:
    0
    Views:
    344
    Microsoft Newsserver
    Apr 18, 2008
  4. Ken Kast

    Relative Absolute Position

    Ken Kast, Jul 27, 2003, in forum: Javascript
    Replies:
    4
    Views:
    166
    Richard Cornford
    Jul 28, 2003
  5. Chris Leonard

    How to get the absolute position of an element

    Chris Leonard, Aug 31, 2003, in forum: Javascript
    Replies:
    5
    Views:
    124
    Chris Leonard
    Sep 2, 2003
Loading...

Share This Page