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

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

David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions

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

Contents

  David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-11-10 06:09 -0800
    Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions "J.R." <groups_jr-1@yahoo.com.br> - 2011-11-10 16:57 -0200
      Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-11-10 11:54 -0800
    Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions "Ant" <not@home.today> - 2011-11-10 19:47 +0000
      Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-11-10 13:07 -0800
      Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Matt McDonald <matt@fortybelow.ca> - 2011-11-10 14:12 -0700
        Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-11-11 07:26 -0800
        Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 -   How to Measure Element Dimensions Frobernik <nospam@nospam.com> - 2011-11-17 22:43 +0000
          Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-02 16:08 -0800
            Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How   to Measure Element Dimensions Frobernik <nospam@nospam.com> - 2011-12-06 21:18 +0000
              Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-06 14:13 -0800
      Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Gene Wirchenko <genew@ocis.net> - 2011-11-10 13:17 -0800
      Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions "Evertjan." <exjxw.hannivoort@interxnl.net> - 2011-11-10 22:43 +0000
      Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions "Richard Cornford" <Richard@litotes.demon.co.uk> - 2011-11-11 00:36 +0000
        Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Gene Wirchenko <genew@ocis.net> - 2011-11-10 19:14 -0800
          Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions "Richard Cornford" <Richard@litotes.demon.co.uk> - 2011-11-11 09:59 +0000
            Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Gene Wirchenko <genew@ocis.net> - 2011-11-11 11:04 -0800
          Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2011-11-11 14:39 +0100
        Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2011-11-12 10:38 +0100
          Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions "Richard Cornford" <Richard@litotes.demon.co.uk> - 2011-11-12 19:19 +0000
            Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2011-11-12 21:07 +0100
              Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-13 00:42 +0100
              Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions "Richard Cornford" <Richard@litotes.demon.co.uk> - 2011-11-13 14:33 +0000
                Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2011-11-17 23:14 +0100
                  Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions "Richard Cornford" <Richard@litotes.demon.co.uk> - 2011-11-17 23:55 +0000
            Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2011-11-13 20:22 +0100
          Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions RobG <rgqld@iinet.net.au> - 2011-11-13 08:29 +1000
            Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2011-11-13 20:25 +0100
              Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions RobG <rgqld@iinet.net.au> - 2011-11-13 23:05 -0800
                Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Tim Down <timdown@gmail.com> - 2011-11-14 03:41 -0800
                  Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions RobG <rgqld@iinet.net.au> - 2011-11-16 16:18 -0800
                  Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-02 16:03 -0800
                Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2011-11-15 16:52 +0100
                Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-02 15:54 -0800
          Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2011-11-13 10:38 +0200
    Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Dr J R Stockton <reply1145@merlyn.demon.co.uk> - 2011-11-11 21:33 +0000
      Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-02 15:00 -0800
      Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-02 18:38 -0800
        Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions "J.R." <groups_jr-1@yahoo.com.br> - 2011-12-03 19:50 -0200
          Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-03 15:50 -0800
          Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-03 16:38 -0800
            Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-03 17:14 -0800
              Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2011-12-04 11:07 +0100
                Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-04 02:45 -0800
            Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-04 13:37 -0800
              Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-04 16:01 -0800
                Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-04 16:28 -0800
                  Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-04 18:56 -0800
                    Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions John G Harris <john@nospam.demon.co.uk> - 2011-12-05 14:39 +0000
                      Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-05 11:00 -0800
          Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-03 19:17 -0800
    Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions "J.R." <groups_jr-1@yahoo.com.br> - 2011-11-13 00:06 -0200
      Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-13 04:31 +0100
        Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions "J.R." <groups_jr-1@yahoo.com.br> - 2011-11-13 13:44 -0200
          Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-13 18:35 +0100
            Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions "J.R." <groups_jr-1@yahoo.com.br> - 2011-11-13 22:00 -0200
              Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-14 12:40 +0100
                Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions "J.R." <groups_jr-1@yahoo.com.br> - 2011-11-14 11:52 -0200
                  Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-14 15:40 +0100
            Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2011-11-17 11:16 +0100
              Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-17 21:06 +0100
                Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2011-11-17 22:13 +0100
          Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-02 15:19 -0800
      Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-02 15:10 -0800
        Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-02 18:04 -0800

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#8270

"Richard Cornford" <Richard@litotes.demon.co.uk> writes:

> document.write(
>  "<scr"+"ipt type='text/javascript' src='"+tmps[x]+"'></scr"+"ipt>"
> );
>
> The cargo-cult programming structure is the first (left-most) string
> concatenation operation. The final (right-most) string concatenation
> operation has some justification in some contexts. Its use in those
> contexts demonstrates a shallow understanding of the reasons for its
> use (as there are more efficient, shorter and more formally correct
> alternatives), and it was almost certainly that shallow understanding
> that inspired the real cargo-cult structure to the left. However, One
> context where the final (right-most) concatenation is purposeless is
> when it is found in an imported JS file, which is of course where
> Google's code search is finding it. So that too is pushing cargo-cult
> programming in the contexts where it is being found above.

I’m getting the impression that you think that the purpose of splitting
and concatenating the generic identifier is somehow related to escaping
the ETAGO delimiter (‘</’), while it is much more likely to be related
to Norton ‘Internet Security’ inserting it’s dreaded SymError function
after the first instance of anything that looks like the start tag of a
script element (and ususally messing things up in the process).

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

#8272

Eric Bednarz wrote:

> "Richard Cornford" <Richard@litotes.demon.co.uk> writes:
>> document.write(
>>  "<scr"+"ipt type='text/javascript' src='"+tmps[x]+"'></scr"+"ipt>"
>> );
>>
>> The cargo-cult programming structure is the first (left-most) string
>> concatenation operation. The final (right-most) string concatenation
>> operation has some justification in some contexts. Its use in those
>> contexts demonstrates a shallow understanding of the reasons for its
>> use (as there are more efficient, shorter and more formally correct
>> alternatives), and it was almost certainly that shallow understanding
>> that inspired the real cargo-cult structure to the left. However, One
>> context where the final (right-most) concatenation is purposeless is
>> when it is found in an imported JS file, which is of course where
>> Google's code search is finding it. So that too is pushing cargo-cult
>> programming in the contexts where it is being found above.
> 
> I’m getting the impression that you think that the purpose of splitting
> and concatenating the generic identifier is somehow related to escaping
> the ETAGO delimiter (‘</’), while it is much more likely to be related
> to Norton ‘Internet Security’ inserting it’s dreaded SymError function
> after the first instance of anything that looks like the start tag of a
> script element (and ususally messing things up in the process).

Suppose that was the case, then it would be a Bad Idea to work around that.  
Either it is a bug in Norton InSecurity, then working around it will help to 
keep it forever, having everyone to jump forever through the hoops that 
Symantec's incompetent, greedy developers once set up.  Or it is a feature, 
then one would ignore the user's wishes, which is always a bad idea.


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]

#8281

Eric Bednarz wrote:
> Richard Cornford writes:
>
>> document.write(
>> "<scr"+"ipt type='text/javascript' src='"+tmps[x]+"'></scr"+"ipt>"
>> );
>>
>> The cargo-cult programming structure is the first (left-most)
>> string concatenation operation. The final (right-most) string
>> concatenation operation has some justification in some contexts.
>> Its use in those contexts demonstrates a shallow understanding
>> of the reasons for its use (as there are more efficient, shorter
>> and more formally correct alternatives), and it was almost
>> certainly that shallow understanding that inspired the real
>> cargo-cult structure to the left. However, One context where
>> the final (right-most) concatenation is purposeless is when it
>> is found in an imported JS file, which is of course where
>> Google's code search is finding it. So that too is pushing
>> cargo-cult programming in the contexts where it is being found
>> above.
>
> I’m getting the impression that you think that the purpose of
> splitting and concatenating the generic identifier is somehow
> related to escaping the ETAGO delimiter (‘</’),

"Somehow related" seems applicable.

> while it is much more likely to be related to Norton ‘Internet
> Security’ inserting it’s dreaded SymError function after the
> first instance of anything that looks like the start tag of a
> script element (and ususally messing things up in the process).

In a cause and effect relationship I would expect the cause to pre-date 
the effect. This concatenation 'trick' was common when I started working 
with javascript in 2001. The odds are that it pre-dates Norton 'internet 
security' and my observations of Norton's inserted scripts have been 
that it has been varying over time. So it seems more likely that 
observing this common practice allowed the incompetent scripters at 
Norton to justify not parsing the HTML they modify, and so the pertinent 
cause and effect relationship here could be the other way around (though 
"Post hoc ergo propter hoc" is a logical fallacy, so maybe not).

I also don't think that the mindset where people are scripting only for 
the default configurations of the most recent versions of 4 or 5 known 
browsers will tend to leave then thinking about the possible actions of 
'security' proxies (or being willing to take action to accommodate them 
if they did).

In any event, HTML mark-up modification is still not relevant to the 
contents of an imported javascript.

Richard. 

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

#8395

"Richard Cornford" <Richard@litotes.demon.co.uk> writes:

> Eric Bednarz wrote:
>> Richard Cornford writes:
>>
>>> document.write(
>>> "<scr"+"ipt type='text/javascript' src='"+tmps[x]+"'></scr"+"ipt>"
>>> );
>>>
>>> The cargo-cult programming structure is the first (left-most)
>>> string concatenation operation. The final (right-most) string
>>> concatenation operation has some justification in some contexts.
>>> Its use in those contexts demonstrates a shallow understanding
>>> of the reasons for its use (as there are more efficient, shorter
>>> and more formally correct alternatives), and it was almost
>>> certainly that shallow understanding that inspired the real
>>> cargo-cult structure to the left. However, One context where
>>> the final (right-most) concatenation is purposeless is when it
>>> is found in an imported JS file, which is of course where
>>> Google's code search is finding it. So that too is pushing
>>> cargo-cult programming in the contexts where it is being found
>>> above.
>>
>> I’m getting the impression that you think that the purpose of
>> splitting and concatenating the generic identifier is somehow
>> related to escaping the ETAGO delimiter (‘</’),
>
> "Somehow related" seems applicable.

Well, I don’t understand what you mean by “some justification in some
contexts”. In the context of a CDATA content model it doesn’t make any
sense at all because CDATA ends with ETAGO foolowed by a name start
character. So that habit wouldn’t have made it valid HTML (4) either.

>> while it is much more likely to be related to Norton ‘Internet
>> Security’ inserting it’s dreaded SymError function after the
>> first instance of anything that looks like the start tag of a
>> script element (and ususally messing things up in the process).
>
> In a cause and effect relationship I would expect the cause to
> pre-date the effect. This concatenation 'trick' was common when I
> started working with javascript in 2001.

Well, I’m unlikely to ever catch up with that head start. :-)

References I’ve seen connecting this practice with NIS were from around
2004 to 2006, as far as I can remember.

> The odds are that it
> pre-dates Norton 'internet security'

But why? Were there *practical* problems that are not related to
validation?

> and my observations of Norton's
> inserted scripts have been that it has been varying over time.

That’s inherent with cat and mouse games. For a while it seems to have
been possible to prevent NIS from modifying the first script element in
the HTML source by preceding it with an HTML comment containing script
markup (this kind of thing is pretty hard to verify now, but it sounds
plausible; ad-hoc parsing is usually broken and gets fixed feature by
feature later).

> I also don't think that the mindset where people are scripting only
> for the default configurations of the most recent versions of 4 or 5
> known browsers will tend to leave then thinking about the possible
> actions of 'security' proxies (or being willing to take action to
> accommodate them if they did).

It doesn’t create much overhead, and might have been a best practice
that is so good that nobody checks what it is for ;-)

On the other hand, it’s really not easy to know which cargo cult bits
are redundant or not, and why. Somewhere around 2007 I removed HTML
comments out of script elements in the course of a redesign of a
website. I got kicked royally for that because the client had some
really crappy HTML to PDF conversion software that included the script
content after that.

> In any event, HTML mark-up modification is still not relevant to the
> contents of an imported javascript.

But it is supposed to have been *only* about external script, the
premise being that NIS was looking for the first occurance of something
that looks like a start tag of a script element, which isn’t a problem
in a HTML context.

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

#8398

Eric Bednarz wrote:
> Richard Cornford writes:
>> Eric Bednarz wrote:
>>> Richard Cornford writes:
>>>
>>>> document.write(
>>>> "<scr"+"ipt type='text/javascript' src='"+tmps[x]+
>>>>                                    "'></scr"+"ipt>"
>>>> );
>>>>
>>>> The cargo-cult programming structure is the first (left-most)
>>>> string concatenation operation. The final (right-most) string
>>>> concatenation operation has some justification in some contexts.
>>>> Its use in those contexts demonstrates a shallow understanding
>>>> of the reasons for its use (as there are more efficient, shorter
>>>> and more formally correct alternatives), and it was almost
>>>> certainly that shallow understanding that inspired the real
>>>> cargo-cult structure to the left. However, One context where
>>>> the final (right-most) concatenation is purposeless is when it
>>>> is found in an imported JS file, which is of course where
>>>> Google's code search is finding it. So that too is pushing
>>>> cargo-cult programming in the contexts where it is being found
>>>> above.
>>>
>>> I’m getting the impression that you think that the purpose of
>>> splitting and concatenating the generic identifier is somehow
>>> related to escaping the ETAGO delimiter (‘</’),
>>
>> "Somehow related" seems applicable.
>
> Well, I don’t understand what you mean by "some justification
> in some contexts". In the context of a CDATA content model it
> doesn’t make any sense at all because CDATA ends with ETAGO
> foolowed by a name start character. So that habit wouldn’t have
> made it valid HTML (4) either.

Do you really not know this? Unexpected but never mind. Real world 
browsers (as you know) use tag-soup parsers instead of (formal) HTML 
parsers, so they tend not to care about ETAGO terminating CDATA. 
However, even tag soup parsers need to delimit the sequence of 
characters they are going to send to the javascript engine, and they do 
that by looking for the (case insensitive) character sequence </script>. 
They assume an open script element is terminated by the next occurrence 
of that sequence that they find, even if that sequence is actually 
supposed to be part of the javascript source code. To avoid the 
javascript source placed inside a script element from being prematurely 
terminated it is normal to break up any </script> charter sequences 
within that source code. And one of the techniques for braking that 
sequence up has been the final concatenation "trick" illustrated above.

In source code that appears within script tags in HTML page the 
recommended practice is to break up the </script> sequence by putting a 
backslash (escape) character just before the forward slash to give 
<\/script>. This addresses the practical problem of preventing the 
mark-up parser from mistaking it for the closing script tag and more 
efficiently than the concatenation "trick" because the escape sequence 
is handled during the tokenization of the javascript source code so 
there is no runtime overhead (and it is shorter and probably quicker to 
tokenise than the concatenation code). Plus this also happens to deal 
with the ETAGO, if mark-up validity is something that is valued.

>>> while it is much more likely to be related to Norton ‘Internet
>>> Security’ inserting it’s dreaded SymError function after the
>>> first instance of anything that looks like the start tag of a
>>> script element (and ususally messing things up in the process).
>>
>> In a cause and effect relationship I would expect the cause to
>> pre-date the effect. This concatenation 'trick' was common when
>> I started working with javascript in 2001.
>
> Well, I’m unlikely to ever catch up with that head start. :-)
>
> References I’ve seen connecting this practice with NIS were
> from around 2004 to 2006, as far as I can remember.
>
>> The odds are that it
>> pre-dates Norton 'internet security'
>
> But why? Were there *practical* problems that are not related to
> validation?

Yes, as described above.

>> and my observations of Norton's
>> inserted scripts have been that it has been varying over time.
>
> That’s inherent with cat and mouse games. For a while it seems
> to have been possible to prevent NIS from modifying the first
> script element in the HTML source by preceding it with an HTML
> comment containing script markup (this kind of thing is pretty
> hard to verify now, but it sounds plausible; ad-hoc parsing is
> usually broken and gets fixed feature by feature later).

Yep, it is a fools errand to try to do anything to compensate.

>> I also don't think that the mindset where people are scripting
>> only for the default configurations of the most recent versions
>> of 4 or 5 known browsers will tend to leave then thinking about
>> the possible actions of 'security' proxies (or being willing to
>> take action to accommodate them if they did).
>
> It doesn’t create much overhead, and might have been a best
> practice that is so good that nobody checks what it is for ;-)

It has been a recommended practice, intended for an HTML context. And it 
certainly is harmless.

> On the other hand, it’s really not easy to know which cargo cult
> bits are redundant or not, and why.

An examination of the reasoning that justifies them is frequently 
enough. With the absence of any stated justification being a pretty good 
clue on its own.

> Somewhere around 2007 I
> removed HTML comments out of script elements in the course of
> a redesign of a website. I got kicked royally for that because
> the client had some really crappy HTML to PDF conversion software
> that included the script content after that.

But you would have learnt that sooner if you had never included them in 
the first place, and they were redundant in their original role by 2001. 
Then you would only have had to add them once (or possibly the client 
would have got a better converter to start with).

>> In any event, HTML mark-up modification is still not relevant to
>> the contents of an imported javascript.
>
> But it is supposed to have been *only* about external script, the
> premise being that NIS was looking for the first occurance of
> something that looks like a start tag of a script element, which
> isn’t a problem in a HTML context.

You are going to have to explain that better as I don't see the point 
you are making there.

Richard. 

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

#8287

On Sat, 12 Nov 2011 19:19:45 -0000, Richard Cornford wrote:

><scr("|')\+("|')ipt lang:javascript
>
>- of which a representative example (from an old dojo version, and 
>re-wrapped for posting) is:-
>
>document.write(
>  "<scr"+"ipt type='text/javascript' src='"+tmps[x]+"'></scr"+"ipt>"
>);

Thanks again! Nice examples.

Hans-Georg

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

#8271

On 12/11/11 7:38 PM, Hans-Georg Michna wrote:
> On Fri, 11 Nov 2011 00:36:57 -0000, Richard Cornford wrote:
>>
>> So, an illustration, but which one? Try this, go to
>> <URL: http://www.google.com/codesearch>
>> and in the search box at the top of the page enter the following line:-
>>
>> typeof\s*\(?\s*[\S]+\s*\)?\s*(!|=)==?\s*("|')array("|') lang:javascript
>>
>> - and do the search. It gets 4,000+ results (including from a
>> cross-section of 'popular' libraries) along the lines of:-
>
> Nice! I just got 19,000+ hits. Strange that it varies so much.
>
> Anyway, do you have more examples? These would be good demos of
> the general ignorance towards correct JavaScript programming.
> Good for demos.

One that is specific to jQuery is the use, usually within a listener, of 
the expression:

   $(this).val()

Searching at Google code search with:

   \$\(this\)\.val\(\) lang:javascript

returns over 5,000 hits.


-- 
Rob

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

#8288

On Sun, 13 Nov 2011 08:29:54 +1000, RobG wrote:

>On 12/11/11 7:38 PM, Hans-Georg Michna wrote:

>>[...]
>> Anyway, do you have more examples? These would be good demos of
>> the general ignorance towards correct JavaScript programming.
>> Good for demos.

>One that is specific to jQuery is the use, usually within a listener, of 
>the expression:
>
>   $(this).val()
>
>Searching at Google code search with:
>
>   \$\(this\)\.val\(\) lang:javascript
>
>returns over 5,000 hits.

Please help my vague memories of jQuery. What is it that .val()
does? Or do you mean that the $(...) is simply superfluous?

Hans-Georg

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

#8305

On Nov 14, 5:25 am, Hans-Georg Michna <hans-
georgNoEmailPle...@michna.com> wrote:
> On Sun, 13 Nov 2011 08:29:54 +1000, RobG wrote:
> >On 12/11/11 7:38 PM, Hans-Georg Michna wrote:
> >>[...]
> >> Anyway, do you have more examples? These would be good demos of
> >> the general ignorance towards correct JavaScript programming.
> >> Good for demos.
> >One that is specific to jQuery is the use, usually within a listener, of
> >the expression:
>
> >   $(this).val()
>
> >Searching at Google code search with:
>
> >   \$\(this\)\.val\(\) lang:javascript
>
> >returns over 5,000 hits.
>
> Please help my vague memories of jQuery. What is it that .val()
> does? Or do you mean that the $(...) is simply superfluous?

It can be replaced with the very much faster (and less to type):

    this.value;

$(this) "wraps" the target in a jQuery object (quite expensive in
performance terms).

The val() method does some fixing of issues with select elements and
option values, but they are well known and can be dealt with in the
markup.



--
Rob

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

#8308

On Nov 14, 7:05 am, RobG <rg...@iinet.net.au> wrote:
> On Nov 14, 5:25 am, Hans-Georg Michna <hans-
> georgNoEmailPle...@michna.com> wrote:
> > On Sun, 13 Nov 2011 08:29:54 +1000, RobG wrote:
> > >On 12/11/11 7:38 PM, Hans-Georg Michna wrote:
> > >>[...]
> > >> Anyway, do you have more examples? These would be good demos of
> > >> the general ignorance towards correct JavaScript programming.
> > >> Good for demos.
> > >One that is specific to jQuery is the use, usually within a listener, of
> > >the expression:
>
> > >   $(this).val()
>
> > >Searching at Google code search with:
>
> > >   \$\(this\)\.val\(\) lang:javascript
>
> > >returns over 5,000 hits.
>
> > Please help my vague memories of jQuery. What is it that .val()
> > does? Or do you mean that the $(...) is simply superfluous?
>
> It can be replaced with the very much faster (and less to type):
>
>     this.value;
>
> $(this) "wraps" the target in a jQuery object (quite expensive in
> performance terms).
>
> The val() method does some fixing of issues with select elements and
> option values, but they are well known and can be dealt with in the
> markup.

It also messes around with new lines and strips out CR carriage return
characters in the value in attempt to normalize browser behaviour.
However, this seems less than helpful to me: I can see no practical
advantage to it and it causes properties such as selectionStart and
selectionEnd to be unreliable as character indexes within a value
returned by val().

Tim

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

#8380

On Nov 14, 9:41 pm, Tim Down <timd...@gmail.com> wrote:
> On Nov 14, 7:05 am, RobG <rg...@iinet.net.au> wrote:
>
> > On Nov 14, 5:25 am, Hans-Georg Michna <hans-
> > georgNoEmailPle...@michna.com> wrote:
> > > On Sun, 13 Nov 2011 08:29:54 +1000, RobG wrote:
> > > >On 12/11/11 7:38 PM, Hans-Georg Michna wrote:
> > > >>[...]
> > > >> Anyway, do you have more examples? These would be good demos of
> > > >> the general ignorance towards correct JavaScript programming.
> > > >> Good for demos.
> > > >One that is specific to jQuery is the use, usually within a listener, of
> > > >the expression:
>
> > > >   $(this).val()
>
> > > >Searching at Google code search with:
>
> > > >   \$\(this\)\.val\(\) lang:javascript
>
> > > >returns over 5,000 hits.
>
> > > Please help my vague memories of jQuery. What is it that .val()
> > > does? Or do you mean that the $(...) is simply superfluous?
>
> > It can be replaced with the very much faster (and less to type):
>
> >     this.value;
>
> > $(this) "wraps" the target in a jQuery object (quite expensive in
> > performance terms).
>
> > The val() method does some fixing of issues with select elements and
> > option values, but they are well known and can be dealt with in the
> > markup.
>
> It also messes around with new lines and strips out CR carriage return
> characters in the value in attempt to normalize browser behaviour.
> However, this seems less than helpful to me: I can see no practical
> advantage to it and it causes properties such as selectionStart and
> selectionEnd to be unreliable as character indexes within a value
> returned by val().

Looking at the documentation for .val[1] (which is included under
"attributes"), the example uses $(this).val(), adding weight to its
categorisation as "cargo cult programming".

The documentation also says that .val returns "String, Number, Array",
which suggests that it returns String, Number or Array objects. It
will return an array in only one case: the values of a multiple
select. Allowing for sloppy documentation and that they really meant
that it might also return string or number primitives, I can't see any
case where it should return a number.

1.  <URL: http://api.jquery.com/val/ >


--
Rob

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

#8790

On Nov 14, 6:41 am, Tim Down <timd...@gmail.com> wrote:
> On Nov 14, 7:05 am,RobG<rg...@iinet.net.au> wrote:
>
>
>
>
>
>
>
>
>
> > On Nov 14, 5:25 am, Hans-Georg Michna <hans-
> > georgNoEmailPle...@michna.com> wrote:
> > > On Sun, 13 Nov 2011 08:29:54 +1000,RobGwrote:
> > > >On 12/11/11 7:38 PM, Hans-Georg Michna wrote:
> > > >>[...]
> > > >> Anyway, do you have more examples? These would be good demos of
> > > >> the general ignorance towards correctJavaScriptprogramming.
> > > >> Good for demos.
> > > >One that is specific tojQueryis the use, usually within a listener, of
> > > >the expression:
>
> > > >   $(this).val()
>
> > > >Searching atGooglecode search with:
>
> > > >   \$\(this\)\.val\(\) lang:javascript
>
> > > >returns over 5,000 hits.
>
> > > Please help my vague memories ofjQuery. What is it that .val()
> > > does? Or do you mean that the $(...) is simply superfluous?
>
> > It can be replaced with the very much faster (and less to type):
>
> >     this.value;
>
> > $(this) "wraps" the target in ajQueryobject (quite expensive in
> > performance terms).
>
> > The val() method does some fixing of issues with select elements and
> > option values, but they are well known and can be dealt with in the
> > markup.
>
> It also messes around with new lines and strips out CR carriage return
> characters in the value in attempt to normalize browser behaviour.
> However, this seems less than helpful to me: I can see no practical
> advantage to it and it causes properties such as selectionStart and
> selectionEnd to be unreliable as character indexes within a value
> returned by val().
>

Yes, depending on needs, I'd say that's a considerable drawback or of
no benefit.  Trying to do too much "normalization" is one of the
script's problems.  As mentioned, it screws up height/width in similar
fashion, making them unusable in some contexts (e.g. border box
model).

Considering what a function will be used for is of primary concern for
a solid design.  Unfortunately, when you've got thousands of users and
contributors, each with their own specific needs, it's hard to reach a
consensus on use cases.  You end up with mush that sloshes back and
forth over the years as the code base is pulled and pushed by
competing concerns.  Also see attr/removeAttr and the recently
introduced prop/removeProp.

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

#8353

On Sun, 13 Nov 2011 23:05:49 -0800 (PST), RobG wrote:

>It can be replaced with the very much faster (and less to type):
>
>    this.value;
>
>$(this) "wraps" the target in a jQuery object (quite expensive in
>performance terms).
>
>The val() method does some fixing of issues with select elements and
>option values, but they are well known and can be dealt with in the
>markup.

Thanks! Another interesting example.

Hans-Georg

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

#8789

On Nov 14, 2:05 am, RobG <rg...@iinet.net.au> wrote:
> On Nov 14, 5:25 am, Hans-Georg Michna <hans-
>
>
>
>
>
>
>
>
>
> georgNoEmailPle...@michna.com> wrote:
> > On Sun, 13 Nov 2011 08:29:54 +1000,RobGwrote:
> > >On 12/11/11 7:38 PM, Hans-Georg Michna wrote:
> > >>[...]
> > >> Anyway, do you have more examples? These would be good demos of
> > >> the general ignorance towards correctJavaScriptprogramming.
> > >> Good for demos.
> > >One that is specific tojQueryis the use, usually within a listener, of
> > >the expression:
>
> > >   $(this).val()
>
> > >Searching atGooglecode search with:
>
> > >   \$\(this\)\.val\(\) lang:javascript
>
> > >returns over 5,000 hits.
>
> > Please help my vague memories ofjQuery. What is it that .val()
> > does? Or do you mean that the $(...) is simply superfluous?
>
> It can be replaced with the very much faster (and less to type):
>
>     this.value;

Well, not necessarily.  A better (or worse, depending on view) example
of this cargo cult pattern would be:

$(this).attr('id');

Now, anything like that is clearly BS on many levels: performance,
reliability, etc. It's a major misunderstanding.

>
> $(this) "wraps" the target in ajQueryobject (quite expensive in
> performance terms).

Absolutely.  But, in this case, the (rather unfortunately named) "val"
method may be useful.  It's just unfortunate how jQuery works (create
a huge object, discard same), turning every line into an epic snarl of
function calls, created objects, etc.

But if there are more than text inputs (or selects in very specific
contexts) involved, a "getInputValue" function of some sort is in
order.  God knows, I wouldn't trust jQuery's rendition.


This is indeed one viable rendition:-

function getInputValue(el) {
  return el.value;
}

But you have to know when it is appropriate.  The renditions get
larger as you accommodate checkboxes, radio buttons, etc. as typically
this type of function is interested in the value that will be
submitted to the server (if any).  And, as mentioned, unless you set
down strict rules for selects, you can't use the above with them
either.

>
> The val() method does some fixing of issues with select elements and
> option values, but they are well known and can be dealt with in the
> markup.

Right.  I suppose it tries; but wouldn't even waste the time reading
the code.  I imagine it accounts for unchecked inputs and returns
array of strings for multi select as well.  Pretty standard stuff that
hasn't changed... ever.  Unlikely jQuery has put some must-have new
spin on form control serialization.  I did see where somebody said the
docs state their "val" function may return a number.  That I did not
expect.  :)

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

#8277

2011-11-12 11:38, Hans-Georg Michna wrote:

>> typeof\s*\(?\s*[\S]+\s*\)?\s*(!|=)==?\s*("|')array("|') lang:javascript
>>
>> - and do the search. It gets 4,000+ results (including from a
>> cross-section of 'popular' libraries) along the lines of:-
>
> Nice! I just got 19,000+ hits. Strange that it varies so much.

And I got alternatingly 2,900 or 2,667.

It's not that strange that it varies. The common Google search is known 
to give varying results depending on Google server used (e.g. 
www.google.com vs. www.google.de), language settings, Google 
customization options, cookies (carrying e.g. information about past 
searches), browser and the request headers it sends, and possibly phase 
of the moon. There is most probably intentional randomization, too, due 
to Google testing new functionality or just carrying out A/B testing or 
something similar.

Google code search may have any of these causes of variation, and maybe 
some more too.

Moreover, the figures that Google tells us are, well, just figures it 
tells us. They probably reflect some internal hit counts. But if you try 
scan through the results, clicking on the last of the results page 
number in the list at the bottom, you may observe that the hit count 
drops at some point. In my test in this case, page 19 said
"Results 181 - 190 of 2,665"
but clicking on "Next" led to
"Your search - typeof\s*\(?\s*[\S]+\s*\)?\s*(!|=)==?\s*("|')array("|') 
lang:javascript - did not match any documents."

In the common Google search, it seems that at some point, Google set an 
upper limit of 999 on the number of hits it actually shows to the user. 
That is, when the user proceeds from one hit page to the next, or takes 
a shortcut via the page number links, Google stops showing results at 
some point, apparently so that in no circumstances can you go past 
result 999. So the count that it initially gives can be just about 
anything. I don't think it's completely arbitrary, but it surely isn't a 
reliable count of anything.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

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

#8247

In comp.lang.javascript message <bd12b66f-33f5-43d2-8e22-6f81b42c3d8b@n1
4g2000vbn.googlegroups.com>, Thu, 10 Nov 2011 06:09:29, David Mark
<dmark.cinsoft@gmail.com> posted:

>How to Measure Element Dimensions

It could be useful if there were, linked from within each posted Tip, a
Web Index of Tips, linking to Web copies.

One Tip might be the answer to "I have an on-screen element, of known
size, with an on[dbl]click method; how do I obtain the co-ordinates of a
[double-]click with respect to a given position in the element itself?"

The aforementioned index page could have a feedback form, partly for
suggesting topics for tips and possible answers.  The latter, when
imperfect, would provide fodder for further Tips, of course.

In what appears to be the cinsoft home page, "By" should be "To".

Consider a page, <http://www.cinsoft.net/position.html>, which has been
found by a serendipitous Google search for "starting point for a move
animation" or otherwise.  It recommends
        o = getElementPositionStyles(el);
- and that does not work.  The necessary further information is not
clearly provided; indeed, the page seems to have no <a href="...">Home
Page</a>.

-- 
 (c) John Stockton, nr London UK. replyYYWW merlyn demon co uk Turnpike 6.05.
   Web <http://www.uwasa.fi/~ts/http/tsfaq.html> -> Timo Salmi: Usenet Q&A.
   Web <http://www.merlyn.demon.co.uk/news-use.htm> :  about usage of News.
 No Encoding. Quotes precede replies. Snip well. Write clearly. Mail no News.

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

#8786

On Nov 11, 4:33 pm, Dr J R Stockton <reply1...@merlyn.demon.co.uk>
wrote:
> In comp.lang.javascript message <bd12b66f-33f5-43d2-8e22-6f81b42c3d8b@n1
> 4g2000vbn.googlegroups.com>, Thu, 10 Nov 2011 06:09:29, David Mark
> <dmark.cins...@gmail.com> posted:
>
> >How to Measure Element Dimensions
>
> It could be useful if there were, linked from within each posted Tip, a
> Web Index of Tips, linking to Web copies.
>
> One Tip might be the answer to "I have an on-screen element, of known
> size, with an on[dbl]click method; how do I obtain the co-ordinates of a
> [double-]click with respect to a given position in the element itself?"
>
> The aforementioned index page could have a feedback form, partly for
> suggesting topics for tips and possible answers.  The latter, when
> imperfect, would provide fodder for further Tips, of course.

I suppose.


>
> In what appears to be the cinsoft home page, "By" should be "To".
>

Huh?


> Consider a page, <http://www.cinsoft.net/position.html>, which has been
> found by a serendipitous Google search for "starting point for a move
> animation" or otherwise.  It recommends
>         o = getElementPositionStyles(el);
> - and that does not work

It's necessary to have the included script.


 The necessary further information is not
> clearly provided; indeed, the page seems to have no <a href="...">Home
> Page</a>.


Wrong. It's the logo and likely has alt text. Leads to library page.
Site untouched for years; primers not even part of main site or
library. Just a dumping ground for examples that came up here.




Thanks!  Buy the book when it comes out. No UK release date yet.

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

#8794

On Nov 11, 4:33 pm, Dr J R Stockton <reply1...@merlyn.demon.co.uk>
wrote:
>
> One Tip might be the answer to "I have an on-screen element, of known
> size, with an on[dbl]click method; how do I obtain the co-ordinates of a
> [double-]click with respect to a given position in the element itself?"
>

Tricky.  :)

Your best bet is to see the tip of the day related to coordinates.
From that you should be able to get the coordinates of the element
relative to the viewport (or "window" as I think I referred to it in
that post).  So you will need the mouse coordinates relative to the
viewport.  Ironically enough, it's trivial to find those in the old IE
versions that lacked pageX/Y properties.  But for everything else, you
have to have to subtract the scroll position as pageX/Y are relative
to the document.  Depending on context, getting the scroll position is
either trivial (one-liner) or fairly complex.  Frustratingly, it's IE
(all versions AFAIK) that needs most of the extra code in this case.
You also have to consider other factors like whether you will need
this to work in quirks mode (hopefully not)


It looks like:-

// No quirks mode, frames or other windows (just the one running the
script)

var getScrollPosition;

if ('number' == typeof window.pageXOffset) {

  // Many "standards-based" browsers feature this non-standard
property
  // No ambiguity about what this window property means

  getScrollPosition = function() {
    return [window.pageXOffset, window.pageYOffset];
  };
} else if (document.documentElement && 'number' == typeof
document.documentElement.scrollTop) {

  // Proprietary IE properties, copied widely by others; often 0,0 in
mobile browsers,
  // Ambiguous as many mobiles represent an un-scrolled document (i.e.
scrollHeight == clientHeight), regardless of which portion of document
is viewable

  getScrollPosition = function() {
    return [document.documentElement.scrollLeft,
document.documentElement.scrollTop];
  };
}

As usual, simplified feature detection (use isHost* functions) and
untested.  Paste at your own risk.

One other thing, I wouldn't trust that you can get the mouse position
in a click or dblclick listener.  Not sure what the standard
recommendation is, but I know I never retrieve the position from
anything but mousedown/move/up.  ISTM that, at least traditionally,
that's all you can expect to work reliably.  And by "work", I mean
across most browsers released this century.  There's no way anything
like this can be considered cross-browser.  There's at least a couple
of other pairs of properties where at least some mobiles insist on
stashing their "scroll" position (offsetLeft/Top comes to mind).  So
there's at least one more prong and not based on any sort of logic,
just observation.

Needless to say, getting the "viewport" scroll position is something
to avoid whenever possible (most of the time).  But as soon as you
start with the mouse position, at least for years to come, you
introduce that dependency.

Having said all of that, perhaps somebody out there who has actually
needed to tackle this problem has a cleaner, context-specific solution
that works in an acceptable subset of browsers.  The big issue is that
there is no way to feature test the scroll position in advance, short
of actually setting the scroll position (which is clearly out of the
question).

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

#8831

On 03/12/2011 00:38, David Mark wrote:
> On Nov 11, 4:33 pm, Dr J R Stockton<reply1...@merlyn.demon.co.uk>
> wrote:
>>
>> One Tip might be the answer to "I have an on-screen element, of known
>> size, with an on[dbl]click method; how do I obtain the co-ordinates of a
>> [double-]click with respect to a given position in the element itself?"
>>
>
> Tricky.  :)
>
> Your best bet is to see the tip of the day related to coordinates.
>  From that you should be able to get the coordinates of the element
> relative to the viewport (or "window" as I think I referred to it in
> that post).  So you will need the mouse coordinates relative to the
> viewport.  Ironically enough, it's trivial to find those in the old IE
> versions that lacked pageX/Y properties.  But for everything else, you
> have to have to subtract the scroll position as pageX/Y are relative
> to the document.  Depending on context, getting the scroll position is
> either trivial (one-liner) or fairly complex.  Frustratingly, it's IE
> (all versions AFAIK) that needs most of the extra code in this case.
> You also have to consider other factors like whether you will need
> this to work in quirks mode (hopefully not)
>
>
> It looks like:-
>
> // No quirks mode, frames or other windows (just the one running the
> script)
>
> var getScrollPosition;
>
> if ('number' == typeof window.pageXOffset) {
>
>    // Many "standards-based" browsers feature this non-standard
> property
>    // No ambiguity about what this window property means

window.pageYOffset is available as of IE9, FF3+, Safari 4+, Chrome 4+, 
Opera 10+.

IE 8 and older browsers in standards-compliant mode (strict mode) would use:

if (document.documentElement && document.documentElement.scrollTop) {
   return document.documentElement.scrollTop;
}

But IE in quirks mode (tested with IE8) would use:
if (document.body) {
   return document.body.scrollTop;
}

-- 
Joao Rodrigues (J.R.)


>    getScrollPosition = function() {
>      return [window.pageXOffset, window.pageYOffset];
>    };
> } else if (document.documentElement&&  'number' == typeof
> document.documentElement.scrollTop) {
>
>    // Proprietary IE properties, copied widely by others; often 0,0 in
> mobile browsers,
>    // Ambiguous as many mobiles represent an un-scrolled document (i.e.
> scrollHeight == clientHeight), regardless of which portion of document
> is viewable
>
>    getScrollPosition = function() {
>      return [document.documentElement.scrollLeft,
> document.documentElement.scrollTop];
>    };
> }
>
> As usual, simplified feature detection (use isHost* functions) and
> untested.  Paste at your own risk.
>
> One other thing, I wouldn't trust that you can get the mouse position
> in a click or dblclick listener.  Not sure what the standard
> recommendation is, but I know I never retrieve the position from
> anything but mousedown/move/up.  ISTM that, at least traditionally,
> that's all you can expect to work reliably.  And by "work", I mean
> across most browsers released this century.  There's no way anything
> like this can be considered cross-browser.  There's at least a couple
> of other pairs of properties where at least some mobiles insist on
> stashing their "scroll" position (offsetLeft/Top comes to mind).  So
> there's at least one more prong and not based on any sort of logic,
> just observation.
>
> Needless to say, getting the "viewport" scroll position is something
> to avoid whenever possible (most of the time).  But as soon as you
> start with the mouse position, at least for years to come, you
> introduce that dependency.
>
> Having said all of that, perhaps somebody out there who has actually
> needed to tackle this problem has a cleaner, context-specific solution
> that works in an acceptable subset of browsers.  The big issue is that
> there is no way to feature test the scroll position in advance, short
> of actually setting the scroll position (which is clearly out of the
> question).

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

#8833

On Dec 3, 4:50 pm, "J.R." <groups_j...@yahoo.com.br> wrote:
> On 03/12/2011 00:38, David Mark wrote:
>
>
>
>
>
> > On Nov 11, 4:33 pm, Dr J R Stockton<reply1...@merlyn.demon.co.uk>
> > wrote:
>
> >> One Tip might be the answer to "I have an on-screen element, of known
> >> size, with an on[dbl]click method; how do I obtain the co-ordinates of a
> >> [double-]click with respect to a given position in the element itself?"
>
> > Tricky.  :)
>
> > Your best bet is to see the tip of the day related to coordinates.
> >  From that you should be able to get the coordinates of the element
> > relative to the viewport (or "window" as I think I referred to it in
> > that post).  So you will need the mouse coordinates relative to the
> > viewport.  Ironically enough, it's trivial to find those in the old IE
> > versions that lacked pageX/Y properties.  But for everything else, you
> > have to have to subtract the scroll position as pageX/Y are relative
> > to the document.  Depending on context, getting the scroll position is
> > either trivial (one-liner) or fairly complex.  Frustratingly, it's IE
> > (all versions AFAIK) that needs most of the extra code in this case.
> > You also have to consider other factors like whether you will need
> > this to work in quirks mode (hopefully not)
>
> > It looks like:-
>
> > // No quirks mode, frames or other windows (just the one running the
> > script)
>
> > var getScrollPosition;
>
> > if ('number' == typeof window.pageXOffset) {
>
> >    // Many "standards-based" browsers feature this non-standard
> > property
> >    // No ambiguity about what this window property means
>
> window.pageYOffset is available as of IE9, FF3+, Safari 4+, Chrome 4+,
> Opera 10+.

I suspected MS might add those at some point, but never had cause to
confirm. Thanks.

>
> IE 8 and older browsers in standards-compliant mode (strict mode) would use:
>
> if (document.documentElement && document.documentElement.scrollTop) {
>    return document.documentElement.scrollTop;
>
> }
>
> But IE in quirks mode (tested with IE8) would use:
> if (document.body) {
>    return document.body.scrollTop;
>
> }

Something like that.

>
> --
> Joao Rodrigues (J.R.)
>
>
>
> >    getScrollPosition = function() {
> >      return [window.pageXOffset, window.pageYOffset];
> >    };
> > } else if (document.documentElement&&  'number' == typeof
> > document.documentElement.scrollTop) {
>
> >    // Proprietary IE properties, copied widely by others; often 0,0 in
> > mobile browsers,
> >    // Ambiguous as many mobiles represent an un-scrolled document (i.e.
> > scrollHeight == clientHeight), regardless of which portion of document
> > is viewable
>
> >    getScrollPosition = function() {
> >      return [document.documentElement.scrollLeft,
> > document.documentElement.scrollTop];
> >    };
> > }
>
> > As usual, simplified feature detection (use isHost* functions) and
> > untested.  Paste at your own risk.
>
> > One other thing, I wouldn't trust that you can get the mouse position
> > in a click or dblclick listener.  Not sure what the standard
> > recommendation is, but I know I never retrieve the position from
> > anything but mousedown/move/up.  ISTM that, at least traditionally,
> > that's all you can expect to work reliably.  And by "work", I mean
> > across most browsers released this century.  There's no way anything
> > like this can be considered cross-browser.  There's at least a couple
> > of other pairs of properties where at least some mobiles insist on
> > stashing their "scroll" position (offsetLeft/Top comes to mind).  So
> > there's at least one more prong and not based on any sort of logic,
> > just observation.
>
> > Needless to say, getting the "viewport" scroll position is something
> > to avoid whenever possible (most of the time).  But as soon as you
> > start with the mouse position, at least for years to come, you
> > introduce that dependency.
>
> > Having said all of that, perhaps somebody out there who has actually
> > needed to tackle this problem has a cleaner, context-specific solution
> > that works in an acceptable subset of browsers.  The big issue is that
> > there is no way to feature test the scroll position in advance, short
> > of actually setting the scroll position (which is clearly out of the
> > question).

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

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

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

csiph-web