Finding the V offset of an element

[Leonardo Azpurua]

Hi,

I have to place a DIV containing a calendar on top of the input element
where it will store the picked date.

This input element may be contained within another element (ok, I use HTML
tables to organize labels and input controls), which may in turn be
contained within another.

In Opera and FF, the containing hierarchy (inverted) is this:

InputElement
TableCellElement
TableRowElement
TableSectionElement
TableElement
FormElement

I wrote this (very naive) function:

function fullOffsetTop(elt)
{
n = 0;
while (elt && elt.offsetTop)
{
n += elt.offsetTop;
elt = elt.parentNode;
}
return n;
}

Which has two (if not more) problems: first, both TableCellElement and
TableRowElement have the same offset; and also, web-kit based browsers
(Chrome and Safari) either have a different hierarchy or else offsetTop
becomes undefined earlier.

The question is whether there is a safe (and clean, if possible) method to
find out the absolute position of an element, no matter how deeply nested it
is.

TIA
--

[Leonardo Azpurua]

"Leonardo Azpurua" <leon...@exmvps.org> escribió en el mensaje
news:jlgbcm$eti$1...@dont-email.me...

Fiddling more with the problem, I rewrote the fullOffsetTop function thus:

function fullOffsetTop(elt)
{
n = 0;

while (elt)
{
window.alert(elt.toString() + "\noffsetTop = " + elt.offsetTop);
s = elt.toString();
if (elt.offsetTop) n += elt.offsetTop;

elt = elt.parentNode;
}
return n;
}

And found that web-kit based browser have exactly the same hierarchy, but it
was stopping because some intermediate element hadn't the offsetTop property
defined.

Then I noticed that the Form element had the same offset as the Table
element, and so did TableRow and TableSection. So I removed them from the
accumulated total, thus:

function fullOffsetTop(elt)
{
n = 0;

while (elt)
{
s = elt.toString();
if (elt.offsetTop &&
s.indexOf("TableRow") < 0 &&
s.indexOf("Form") < 0) n += elt.offsetTop;

elt = elt.parentNode;
}
return n;
}

Now I seem to be getting (kind of) the intended result.

Nevertheless, it feels messy.

If somebody could point me to a better way of properly placing this element,
I would greatly appreciate it.

TIA,

Leonardo
--

[Leonardo Azpurua]

"Leonardo Azpurua" <leon...@exmvps.org> escribió en el mensaje

news:jlgcp0$kss$1...@dont-email.me...
> [snipped...]

Ok. The thing is activated, in any case, by a mouse click.

So I just added event to the function call arguements, and use event.clientX
andevent.ClientY to position the DIV, and it works (almost) ok.

Now I should calculate whether the X and Y coords plus the height or width
of the DIV lie within the bounds of the browser window.

But I'll care about that tomorrow...

Thanks!
--

[Richard Cornford]

On Apr 4, 3:24 am, Leonardo Azpurua wrote:
> Hi,
>
> I have to place a DIV containing a calendar on top of the inpu

> element where it will store the picked date.
>
> This input element may be contained within another element (ok,
> I use HTML tables to organize labels and input controls), which
> may in turn be contained within another.
>
> In Opera and FF, the containing hierarchy (inverted) is this:
>
> InputElement
> TableCellElement
> TableRowElement
> TableSectionElement
> TableElement
> FormElement
>
> I wrote this (very naive) function:
>
> function fullOffsetTop(elt)
> {
> n = 0;
> while (elt && elt.offsetTop)

^^^^^^^^^^^^^
That is a strange piece of reasoning as this means that as soon as any
specific offset top is zero the calculation of the total offset is
halted.

> {
> n += elt.offsetTop;
> elt = elt.parentNode;

The - offsetTop/Left - properties do not (necessarily) refer to the
offsets from the - parentNode -. Instead they are supposed to refer to
offsets to an element referred to by an - offsetParent - property. So
you sould be working up the chain of - offsetParent -s rather than -
parentNode -s.

> }
> return n;
>
> }
>
> Which has two (if not more) problems: first, both TableCellElement
> and TableRowElement have the same offset;

But they probably also have the same - offsetParent -.

> and also, web-kit based
> browsers (Chrome and Safari) either have a different hierarchy or
> else offsetTop becomes undefined earlier.
>
> The question is whether there is a safe (and clean, if possible)
> method to find out the absolute position of an element, no matter
> how deeply nested it is.

There are no reliable general methods (and the ones that get closest
to being general are quite complex), but given any real-world context
the odds are that a safe and clean method can be created to do the
job.

Richard.

[Hans-Georg Michna]

On Tue, 3 Apr 2012 22:18:28 -0430, Leonardo Azpurua wrote:

> s.indexOf("TableRow") < 0 &&
> s.indexOf("Form") < 0) n += elt.offsetTop;

Just a little remark on the sidelines: IE8 and older cannot do
s.indexOf(...) .

You may want to use something like this instead:

function indexOf(s, a) {
var index = -1;
for (var i = 0; i < a.length; i++) {
if (a[i] === s) {
index = i;
break;
}
}
return index;
}

Hans-Georg

[Richard Cornford]

Array.prototype.indexOf - is not built-in prior to ES5 but -
String.prototype.indexOf - has been around for longer than I have been
using javascript, and it looks to me like - s - is a string, given
that it is a result of a call to - elt.toString() -(which should
return a string primitive). However, relying on a DOM element node
having a - toString - method is dubious (I can't think of an
environment where they don't but there is no requirement that they
will have such a method so no grounds for complaining if any didn't)
and, where they do have such a method, it is doubtful that the
returned string will be constant enough between environments to make
testing for specific sub-strings a reliable practice. It was certainly
the case that IE6 (almost) always returned the string "[object]" from
the - toString - methods of its DOM nodes. In context it would seem
more sensible to be checking something like the - tagName - property
of such elements.

Richard.

[Leonardo Azpurua]

"Hans-Georg Michna" <hans-georgN...@michna.com> escribió en el
mensaje news:tlgon71ol1nd21v94...@4ax.com...

Hi, Hans Georg

Actually, I am not taking into account the existence of IE 8 or earlier.

Your code seems to be searching the first occurence of a character, not of a
string, as String.indexOf does. It should go more along the lines of:

function indexOf(where, pattern)
{
var index = -1;
var pl = pattern.length;
for (var i = 0; i <= where.length - pl; i++)
{
if (where.substr(i, pl) === pattern)

{
index = i;
break;
}
}
return index;
}

My IE6 accepts <class>.prototype.<functionName> = <function>, and I
regularly include an extensions.js file where I could inject the indexOf
function in case it's not defined. But I am not worrying about older
versions of IE, since these applications (if they ever get actually written)
will be running in a rather controlled environment.

While veryfying the correctness of the above statements, I found out that,
in my old IE6 the statement

document.write("indexOf('12345', '45') = " + '12345'.indexOf('45'));

Produces the correct output: indexOf('12345', '45') = 3.

I guess IE6 implementation of js depends on wscript, and I have it updated
to the latest release for XP.


Thanks!

[Eric Bednarz]

Hans-Georg Michna <hans-georgN...@michna.com> writes:

> On Tue, 3 Apr 2012 22:18:28 -0430, Leonardo Azpurua wrote:
>
>> s.indexOf("TableRow") < 0 &&
>> s.indexOf("Form") < 0) n += elt.offsetTop;
>
> Just a little remark on the sidelines: IE8 and older cannot do
> s.indexOf(...) .

Nope (or would the proper contradiction be 'Yep'?). It was rather
obvious from the context that 's' is a string, not an array.

[Thomas 'PointedEars' Lahn]

Richard Cornford wrote:

> Hans-Georg Michna wrote:
>> On Tue, 3 Apr 2012 22:18:28 -0430, Leonardo Azpurua wrote:
>>> s.indexOf("TableRow") < 0 &&
>>> s.indexOf("Form") < 0) n += elt.offsetTop;
>>
>> Just a little remark on the sidelines: IE8 and older cannot do
>> s.indexOf(...) .
>>
>> You may want to use something like this instead:
>>
>> function indexOf(s, a) {
>> var index = -1;
>> for (var i = 0; i < a.length; i++) {
>> if (a[i] === s) {
>> index = i;
>> break;
>> }
>> }
>> return index;
>>
>> }
>
> Array.prototype.indexOf - is not built-in prior to ES5 but -
> String.prototype.indexOf - has been around for longer than I have been

> using javascript, […]

There is no "javascript", there are ECMAScript implementations.

String.protototype.indexOf(string) has been introduced with JavaScript 1.0,
JScript 1.0, and ECMAScript Ed. 1 and is probably supported by all
implementations that are based on the latter and its successors (tests are
pending but no surprises are expected there).


Array.prototype.indexOf(…) is supported since JScript 9.0 in Internet
Explorer 9.0.8112.16421 for Windows 7 Pro 32-bit SP1 in Standards Mode. It
passed all test cases in (Mozilla) JavaScript 1.6 in Firefox 1.5.0.12 for
Windows, and since JavaScript 1.8 (Firefox 3.0.19 for Windows), but
JavaScript 1.7 in Firefox 2.0 for Windows failed test case #10.

It is supported in Google V8 JavaScript since at least version 3.7.12.12 in
Chrome 17.0.963.78 (Developer Build 125577 Linux), Apple JavaScriptCore
since at least version 531.22.7 in Safari for Windows 4.0.5 (531.22.7),
Opera ECMAScript 9.52 in Opera 9.52.10108 for Windows, and KDE JavaScript
since at least version 4.6.5 in Konqueror 4.6.5. Surprisingly, Opera
ECMAScript 8.0 in Opera 8.0.7561 for Windows failed all test cases except
#12.

As such, Array.prototype.indexOf(…) is a feature that cannot be considered
safe for use for the time being, but it is easily emulated.

The test cases were:

(1) jsx.object.isNativeMethod(jsx.global, "Array", "prototype", "indexOf")
(2) var i = new Array().indexOf("foo");
typeof i == "number" && i == -1
(3) var i = new Array("2", 2).indexOf(2);
typeof i == "number" && i == 1
(4) var i = new Array("foo", "foo").indexOf("foo", 1);
typeof i == "number" && i == 1
(5) var i = new Array("foo", "foo").indexOf("foo", "1");
typeof i == "number" && i == 1
(6) var i = new Array("foo").indexOf("bar")
typeof i == "number" && i == -1
(7) var i = new Array("foo", "bar").indexOf("foo", 1);
typeof i == "number" && i == -1
(8) var i = new Array("foo", "bar").indexOf("foo", "1");
typeof i == "number" && i == -1
(9) var i = new Array("foo", "foo").indexOf("foo", -2);
typeof i == "number" && i == 0
(10) var i = new Array("foo").indexOf("foo", 1);
typeof i == "number" && i == -1
(11) var len = Array.prototype.indexOf.length;
typeof len == "number" && len == 1
(12) var o = new Object();
o.indexOf = Array.prototype.indexOf;
o[0] = 42;
o[1] = "42";
o[2] = 42;
o.length = 3;
o.indexOf(42) == 0


HTH

PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)

[Eric Bednarz]

Thomas 'PointedEars' Lahn <Point...@web.de> writes:

> Richard Cornford wrote:

>> [...] has been around for longer than I have been

>> using javascript, […]
>
> There is no "javascript",

I believe the correct expression is "There is no tablet market".

> there are ECMAScript implementations.

Such as

> Google V8 JavaScript

> Apple JavaScriptCore

> Opera ECMAScript

The what?

> Opera 9.52.10108

Oh, Futhark. I suddenly also remember Betamax, and Video 2000.

Anyway. Advanced > Content > [ ] Enable JavaScript

Also, Opera has "Browser JavaScript"
<http://www.opera.com/docs/browserjs/>
and "User JavaScript".
<http://www.opera.com/docs/userjs/>

> KDE JavaScript

Etc.

Of course, there is JScript. For that, see the "JavaScript Reference" at
<http://msdn.microsoft.com/en-us/library/yek4tbz0(v=vs.85).aspx>

[Thomas 'PointedEars' Lahn]

Eric Bednarz wrote:

> Thomas 'PointedEars' Lahn <Point...@web.de> writes:
>> there are ECMAScript implementations.
>
> Such as
>
>> Google V8 JavaScript
>
>> Apple JavaScriptCore
>
>> Opera ECMAScript
>
> The what?

Your lack of (self-)education and inability to quote properly are your
problems alone.

>> Opera 9.52.10108
>
> Oh, Futhark. I suddenly also remember Betamax, and Video 2000.

As long as Opera is officially documenting that on their website, and are
giving no end-of-life dates for their browser versions, I will (have to)
consider that a non-safe version of that implementation. For example, they
have recently removed the documentation for pre-Elektra (6.0) versions, so
those are considered safe by me.

> Anyway. Advanced > Content > [ ] Enable JavaScript
>
> Also, Opera has "Browser JavaScript"
> <http://www.opera.com/docs/browserjs/>
> and "User JavaScript".
> <http://www.opera.com/docs/userjs/>

Opera cannot seem to decide when to call their implementation "JavaScript"
and when "ECMAScript". However, the term "Opera ECMAScript" describes their
implementation better as it is more distinctive from others and the
implementation is closer to ECMAScript than to (Netscape/Mozilla)
JavaScript.

<http://dev.opera.com/articles/view/presto-2-1-web-standards-supported-
by/#commonstandards>
<http://www.opera.com/docs/specs/opera95/#ecmascript>

>> KDE JavaScript
>
> Etc.

There is not much "etc." beyond that. Name at least one implementation that
you deem important and I will consider them.

> Of course, there is JScript.

I have mentioned JScript at least once in the part that you conveniently
snipped.

> For that, see the "JavaScript Reference" at
> <http://msdn.microsoft.com/en-us/library/yek4tbz0(v=vs.85).aspx>

Incorrect. Unfortunately, Microsoft has joined the recent trend for
confusing oversimplification and impreciseness there (which is not atypical
for the MSDN Library, though). However, the documentation for JScript
starts at <http://msdn.microsoft.com/en-us/library/hbxc2t98(VS.85).aspx>,
titled "JScript (ECMAScript3)" and <http://msdn.microsoft.com/en-
us/library/4yyeyb0a(VS.85).aspx>, titled "JScript User's Guide (Windows
Scripting - JScript)".


PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

[Hans-Georg Michna]

Sorry, I was mistaken anyway. Wrote it from memory, which failed
me.

IE8 and earlier lacks the indexOf(...) method on arrays, which
does not apply here.

Hans-Georg

[Hans-Georg Michna]

Yes, you saw right through my mistake. Sorry for the confusion.

Hans-Georg

[Hans-Georg Michna]

On Wed, 4 Apr 2012 04:57:56 -0700 (PDT), Richard Cornford wrote:

>There are no reliable general methods (and the ones that get closest
>to being general are quite complex), but given any real-world context
>the odds are that a safe and clean method can be created to do the
>job.

So the following would not work reliably?

function absTop(el) {
var t = 0;
do t += el.offsetTop;
while (el = el.offsetParent);
return t;
}

Hans-Georg

[Richard Cornford]

For some values of "reliable", yes. It certainly is not a general
solution for providing an accurate value for the total pixel offset of
an element within a displayed document in all contexts. There are other
factors that this will not take account for. For example; the possible
non-zero (top/left) border widths of any element within the chain of -
offsetParent -s. The - offsetTop/Left - is the offset from the inside of
the containing element to the top/left pixel of the contained element,
where the inside is within any borders and the top/left pixel is the
top/left of any border. However, there are contexts where none of the
elements in the - offsetParent -s chain have borders, padding or
margins, where that code might be entirely suitable.

Richard.

[Eric Bednarz]

Thomas 'PointedEars' Lahn <Point...@web.de> writes:

> Eric Bednarz wrote:
>
>> Thomas 'PointedEars' Lahn <Point...@web.de> writes:
>>> there are ECMAScript implementations.
>>
>> Such as
>>
>>> Google V8 JavaScript
>>
>>> Apple JavaScriptCore
>>
>>> Opera ECMAScript
>>
>> The what?
>
> Your lack of (self-)education and inability to quote properly are your
> problems alone.

And I wouldn't have it any other way. Your complete inability to get the
point when it comes to this topic, however, is not my problem.

[Thomas 'PointedEars' Lahn]

You have to make a point yet. I have showed in great detail why it is
misleading at best to subsume all those versions of implementations under
the name "javascript".

[Richard Cornford]

On Apr 4, 9:28 pm, Thomas 'PointedEars' Lahn wrote:
> Richard Cornford wrote:
<snip>

>> Array.prototype.indexOf - is not built-in prior to ES5 but -
>> String.prototype.indexOf - has been around for longer than I

>> have been using javascript, [...]

>
> There is no "javascript", there are ECMAScript implementations.

<snip>

| esoteric:
|
| Adjective:
| Intended for or likely to be understood by only a small number
| of people with a specialized knowledge or interest.
|
| Synonyms:
| occult - private - mystic

Adopting terminology that is likely to give any novice/newcomer the
impression that you are talking about something else entirely is not a
rational approach towards promoting a wider understanding of the
subject.

Richard.

[Thomas 'PointedEars' Lahn]

On the contrary, using umbrella terms just because they are "common" is
likely to give any novice/newcomer the false impression that they already
know what they are doing. Many bad web resources and books about the
subject, and many postings in this newsgroup which in its FAQ promotes that
"javascript" misnomer, are evidence of that.


PointedEars
--
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
-- Richard Cornford, cljs, <cife6q$253$1$8300...@news.demon.co.uk> (2004)

[John G Harris]

On Wed, 4 Apr 2012 at 22:28:51, in comp.lang.javascript, Thomas

'PointedEars' Lahn wrote:
>Richard Cornford wrote:

<snip>

>> Array.prototype.indexOf - is not built-in prior to ES5 but -
>> String.prototype.indexOf - has been around for longer than I have been
>> using javascript, […]
>
>There is no "javascript", there are ECMAScript implementations.

<snip>


#define javascript Any of Union{\
all JavaScript releases, \
all JScript releases, \
all ActionScript releases, \
etc. etc.\
}


Incidentally, "ECMAScript implementations" doesn't include all the
languages that are on-topic for this news group, as Thomas has been told
several times before.


John
--
John Harris

[Gene Wirchenko]

On Thu, 5 Apr 2012 14:54:31 +0100, John G Harris
<jo...@nospam.demon.co.uk> wrote:

[snip]

>Incidentally, "ECMAScript implementations" doesn't include all the
>languages that are on-topic for this news group, as Thomas has been told
>several times before.

There is nothing quite as silly as a wrong pedant who refuses to
correct himself. I mean, what is the point of being a pedant if you
are just going to continue to get it wrong?

Sincerely,

Gene Wirchenko

[Dr J R Stockton]

In comp.lang.javascript message <jlgbcm$eti$1...@dont-email.me>, Tue, 3 Apr
2012 21:54:49, Leonardo Azpurua <leon...@exmvps.org> posted:

>
>The question is whether there is a safe (and clean, if possible) method to
>find out the absolute position of an element, no matter how deeply nested it
>is.

Asking the user to click on a visible mark in the element, and seeing
what you get, has worked for me.

--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms and links;
Astro stuff via astron-1.htm, gravity0.htm ; quotings.htm, pascal.htm, etc.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.

[Leonardo Azpurua]

"Dr J R Stockton" <repl...@merlyn.demon.co.uk.not.invalid> escribió en el
mensaje news:X0BqkKOA...@invalid.uk.co.demon.merlyn.invalid...

> In comp.lang.javascript message <jlgbcm$eti$1...@dont-email.me>, Tue, 3 Apr
> 2012 21:54:49, Leonardo Azpurua <leon...@exmvps.org> posted:
>
>>
>>The question is whether there is a safe (and clean, if possible) method to
>>find out the absolute position of an element, no matter how deeply nested
>>it
>>is.
>
> Asking the user to click on a visible mark in the element, and seeing
> what you get, has worked for me.

Yup... In fact, the DIV is displayed in response to a click event.

So, the "easy" way was to place it centered on the event coordinates.

Thanks!

[Hans-Georg Michna]

Thanks! So does anybody here know of any published routine that
generally solves this problem at least for most not too old
browsers? How about My Library?

Hans-Georg

[Richard Cornford]

On Apr 5, 1:02 pm, Thomas 'PointedEars' Lahn wrote:
> Richard Cornford wrote:
>> Thomas 'PointedEars' Lahn wrote:
>>> Richard Cornford wrote:
>> <snip>
>>>> Array.prototype.indexOf - is not built-in prior to ES5 but -
>>>> String.prototype.indexOf - has been around for longer than I
>>>> have been using javascript, [...]
>
>>> There is no "javascript", there are ECMAScript implementations.
>> <snip>
>
>> | esoteric:
>> |
>> | Adjective:
>> | Intended for or likely to be understood by only a small
>> | number of people with a specialized knowledge or interest.
>> |
>> | Synonyms:
>> | occult - private - mystic
>
>> Adopting terminology that is likely to give any novice/newcomer
>> the impression that you are talking about something else entirely
>> is not a rational approach towards promoting a wider understanding
>> of the subject.
>
> On the contrary, using umbrella terms just because they are "common"
> is likely to give any novice/newcomer the false impression that they
> already know what they are doing.

That is unlikely to be a valid cause and effect relationship. It is
much more likely that people get the impression that they know what
they are doing from observing that they have acquired an ability to
produce "working" product. And if they then need disabusing of that
impression because their "working" is not quite the achievement it
appears to be then that will require their communicating with the
people who have the experience to see the bigger picture.
Dogmatically insisting on the exclusive use of esoteric terminology is
not a strategy designed to promote effective communication.

> Many bad web resources and books about the subject, and many
> postings in this newsgroup which in its FAQ promotes that
> "javascript" misnomer, are evidence of that.

Evidence of a cause and effect relationship between the use of
umbrella terms and people gaining the impression that they know what
they are doing? Observing an effect is only evidence of that effect,
it is not evidence for any relationship between that effect and any
cause.

We already know that there is something about javascript that promotes
a premature overconfidence in the individuals who attempt to learn the
subject, but the causes of that are unlikely to be simple or uniform
and are not under our control in any event (as they will likely have
had their effect before any of us get an opportunity to interact with
the individuals in question). The only worthwhile question is what
would be the best way of moving those individuals forward, and that is
very unlikely to be achieved by shouting arcane jargon from behind the
locked door of an ivory tower.

Richard.