Finding the V offset of an element

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

> Eric Bednarz wrote:
>
>> Thomas 'PointedEars' Lahn <PointedEars@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.

Eric Bednarz wrote:

> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>> Eric Bednarz wrote:
>>> Thomas 'PointedEars' Lahn <PointedEars@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.

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


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

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.

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. 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$8300dec7@news.demon.co.uk> (2004)

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

On Thu, 5 Apr 2012 14:54:31 +0100, John G Harris
<john@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

In comp.lang.javascript message <jlgbcm$eti$1@dont-email.me>, Tue, 3 Apr
2012 21:54:49, Leonardo Azpurua <leonardo@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.

On Thu, 5 Apr 2012 09:38:04 +0100, Richard Cornford wrote:

>Hans-Georg Michna wrote:

>> 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;
>> }

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

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

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.