Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #13206 > unrolled thread

Finding the V offset of an element

Back to article view | Back to comp.lang.javascript

Contents

  Finding the V offset of an element "Leonardo Azpurua" <leonardo@exmvps.org> - 2012-04-03 21:54 -0430
    Re: Finding the V offset of an element "Leonardo Azpurua" <leonardo@exmvps.org> - 2012-04-03 22:18 -0430
      Re: Finding the V offset of an element "Leonardo Azpurua" <leonardo@exmvps.org> - 2012-04-03 22:34 -0430
      Re: Finding the V offset of an element Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2012-04-04 14:49 +0200
        Re: Finding the V offset of an element "Leonardo Azpurua" <leonardo@exmvps.org> - 2012-04-04 10:28 -0430
          Re: Finding the V offset of an element Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2012-04-05 09:12 +0200
        Re: Finding the V offset of an element Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2012-04-04 20:28 +0200
          Re: Finding the V offset of an element Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2012-04-05 09:13 +0200
        Re: Finding the V offset of an element Richard Cornford <Richard@litotes.demon.co.uk> - 2012-04-04 07:05 -0700
          Re: Finding the V offset of an element Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-04 22:28 +0200
            Re: Finding the V offset of an element Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2012-04-05 00:44 +0200
              Re: Finding the V offset of an element Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-05 05:50 +0200
                Re: Finding the V offset of an element Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2012-04-05 11:22 +0200
                  Re: Finding the V offset of an element Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-05 13:21 +0200
            Re: Finding the V offset of an element Richard Cornford <Richard@litotes.demon.co.uk> - 2012-04-05 04:35 -0700
              Re: Finding the V offset of an element Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-05 14:02 +0200
                Re: Finding the V offset of an element Richard Cornford <Richard@litotes.demon.co.uk> - 2012-04-10 09:32 -0700
            Re: Finding the V offset of an element John G Harris <john@nospam.demon.co.uk> - 2012-04-05 14:54 +0100
              Re: Finding the V offset of an element Gene Wirchenko <genew@ocis.net> - 2012-04-05 08:37 -0700
    Re: Finding the V offset of an element Richard Cornford <Richard@litotes.demon.co.uk> - 2012-04-04 04:57 -0700
      Re: Finding the V offset of an element Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2012-04-05 09:16 +0200
        Re: Finding the V offset of an element "Richard Cornford" <Richard@litotes.demon.co.uk> - 2012-04-05 09:38 +0100
          Re: Finding the V offset of an element Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2012-04-08 18:27 +0200
    Re: Finding the V offset of an element Dr J R Stockton <reply1214@merlyn.demon.co.uk.not.invalid> - 2012-04-06 21:52 +0100
      Re: Finding the V offset of an element "Leonardo Azpurua" <leonardo@exmvps.org> - 2012-04-07 11:18 -0430

Page 1 of 2  [1] 2  Next page →

#13206 — Finding the V offset of an element

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

[toc] | [next] | [standalone]

#13207

"Leonardo Azpurua" <leonardo@exmvps.org> escribió en el mensaje 
news:jlgbcm$eti$1@dont-email.me...
> 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.

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

[toc] | [prev] | [next] | [standalone]

#13208

"Leonardo Azpurua" <leonardo@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!
--

[toc] | [prev] | [next] | [standalone]

#13211

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

[toc] | [prev] | [next] | [standalone]

#13213

"Hans-Georg Michna" <hans-georgNoEmailPlease@michna.com> escribió en el 
mensaje news:tlgon71ol1nd21v94gcss1osimv21olv7k@4ax.com...
> 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

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!

[toc] | [prev] | [next] | [standalone]

#13231

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

[toc] | [prev] | [next] | [standalone]

#13214

Hans-Georg Michna <hans-georgNoEmailPlease@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.

[toc] | [prev] | [next] | [standalone]

#13232

On Wed, 04 Apr 2012 20:28:01 +0200, Eric Bednarz wrote:

>Hans-Georg Michna <hans-georgNoEmailPlease@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.

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

Hans-Georg

[toc] | [prev] | [next] | [standalone]

#13216

On Apr 4, 1:49 pm, 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, 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.

[toc] | [prev] | [next] | [standalone]

#13219

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

[toc] | [prev] | [next] | [standalone]

#13223

Thomas 'PointedEars' Lahn <PointedEars@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>

[toc] | [prev] | [next] | [standalone]

#13227

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

[toc] | [prev] | [next] | [standalone]

#13236

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.

[toc] | [prev] | [next] | [standalone]

#13237

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

[toc] | [prev] | [next] | [standalone]

#13238

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.

[toc] | [prev] | [next] | [standalone]

#13239

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)

[toc] | [prev] | [next] | [standalone]

#13315

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.

[toc] | [prev] | [next] | [standalone]

#13240

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

[toc] | [prev] | [next] | [standalone]

#13243

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

[toc] | [prev] | [next] | [standalone]

#13215

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.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web