Need Help Creating an Image Slideshow
Madcap
is basically a "slideshow" of pictures with each picture loading in
the same frame after a delay of some seconds. So, when the user opens
the page/frame it will...
1. Load multiple images from web server (preload all)
2. Display first image
3. Wait xx seconds (different interval for each picture)
4. Load next image
5. Repeat
I could do it all in PHP and use the meta-refresh thing in the HTML,
but then each image wouldn't load until it is time for that image. I
of course want to minimize the delay between images so I thought
javascript would be the way to go.
I am a programmer with PHP/HTML skills but I'm pretty weak in
Javascript. Can you help me get started?
Thomas 'PointedEars' Lahn
> [requirements]
> I am a programmer with PHP/HTML skills
Did you already know ...?
42. HTML is _not_ a programming language.
> but I'm pretty weak in Javascript. Can you help me get started?
Sure. Read <http://jibbering.com/faq/#posting> pp.
HTH
PointedEars
JR
> I want to experiment with a new feature for my web app. The feature
> is basically a "slideshow" of pictures with each picture loading in
> the same frame after a delay of some seconds. So, when the user opens
> the page/frame it will...
>
> 1. Load multiple images from web server (preload all)
Preloading dozens of images, specially when they're full / big sized,
could wear out your webserver resources and waste a lot of bandwidth.
It can be fine to preload only the next / previous image, though.
> I am a programmer with PHP/HTML skills but I'm pretty weak in
> Javascript. Can you help me get started?
I'd like to suggest that you learn Javascript as soon as possible
because it would improve your skills in web development. Besides
reading recommended books (http://www.jibbering.com/faq/#books), a
complementary way to learn any language is studying other developer's
code. This is why I suggest studying these two libraries: Lightbox and
Highslide (Google for these names), although they require other
libraries to work properly.
Cheers,
Joao Rodrigues
Madcap
> could wear out your webserver resources and waste a lot of bandwidth.
> It can be fine to preload only the next / previous image, though.
It's not too bad and it's for members, not just any visitor. I would
estimate about a dozen or so images per 5 minutes per user. But your
point is valid nonetheless. I could probably just preload the next
image at each interval and still avoid the transition delay. I don't
even need to keep the previous. If the user clicks away I've only
wasted one image worth of bandwidth.
> code. This is why I suggest studying these two libraries: Lightbox and
> Highslide (Google for these names), although they require other
> libraries to work properly.
I checked out the sites briefly and bookmarked them. Lightbox looks to
be close to what I'm after, only I need no captions and a timer based
advance rather than buttons. I also got to thinking about animated
gif's, searched google for "animated jpeg" and found what seems to be
the barebones javascript of what I'm after. I just have to pass in
the number and length of the intervals, set the timer to the right
one, loop, etc.
The article also mentioned that the makers of gdlib have a "jpeg
animator" now. Not sure what that's about yet but I'm already using
the gdlib C client for resizing still images and "one stop shopping"
is nice.
Thanks for the advice
-Kerry
Bart Van der Donck
> I want to experiment with a new feature for my web app. The feature
> is basically a "slideshow" of pictures with each picture loading in
> the same frame after a delay of some seconds. So, when the user opens
> the page/frame it will...
>
> 1. Load multiple images from web server (preload all)
> 2. Display first image
> 3. Wait xx seconds (different interval for each picture)
> 4. Load next image
> 5. Repeat
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>Slideshow</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<script type="text/javascript">
var interval = 1.5; // in seconds
var t = 0;
var f = new Array();
f[0] = new Image();
f[0].src = 'http://216.92.6.95/app_pics/large/kCAm14d1JNRM7vn.jpg';
f[1] = new Image();
f[1].src = 'http://216.92.6.95/app_pics/large/YQk8ePvHibk19W6.jpg';
f[2] = new Image();
f[2].src = 'http://216.92.6.95/app_pics/large/H3rmiFJw3MheUaC.jpg';
function refr() {
++t;
if (t >= f.length) t=0;
document.images['pic'].src = f[t].src;
setTimeout('refr()', interval * 1000);
}
</script>
</head>
<body onLoad="setTimeout('refr()', interval * 1000);">
<img name="pic" border="0" alt=""
src="http://216.92.6.95/app_pics/large/kCAm14d1JNRM7vn.jpg">
</body>
</html>
Hope this helps,
--
Bart
Madcap
to my own images and it's working fine.
Thanks!
Thomas 'PointedEars' Lahn
> Madcap wrote:
>> I want to experiment with a new feature for my web app. The feature
>> is basically a "slideshow" of pictures with each picture loading in
>> the same frame after a delay of some seconds. So, when the user opens
>> the page/frame it will...
>>
>> 1. Load multiple images from web server (preload all)
>> 2. Display first image
>> 3. Wait xx seconds (different interval for each picture)
>> 4. Load next image
>> 5. Repeat
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
> "http://www.w3.org/TR/html4/loose.dtd">
> <html>
> <head>
> <title>Slideshow</title>
> <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
> <script type="text/javascript">
> var interval = 1.5; // in seconds
> var t = 0;
Unnecessary global variables.
> var f = new Array();
> f[0] = new Image();
Untested construction of host object.
> f[0].src = 'http://216.92.6.95/app_pics/large/kCAm14d1JNRM7vn.jpg';
> f[1] = new Image();
> f[1].src = 'http://216.92.6.95/app_pics/large/YQk8ePvHibk19W6.jpg';
> f[2] = new Image();
> f[2].src = 'http://216.92.6.95/app_pics/large/H3rmiFJw3MheUaC.jpg';
Unnecessary, harder-to-maintain assignments.
var f = [
"http://216.92.6.95/app_pics/large/kCAm14d1JNRM7vn.jpg",
"http://216.92.6.95/app_pics/large/YQk8ePvHibk19W6.jpg",
"http://216.92.6.95/app_pics/large/H3rmiFJw3MheUaC.jpg"
];
// or: jsx.object.isMethod(jsx.global, "Image"))
var t = typeof Image;
if (/^\s*unknown\s*/i.test(t)
|| /^\s*(function|object)\s*$/i.test(t) && Image)
{
var imageFactory = function(uri) {
var img = new Image();
img.src = uri;
return img;
};
for (var i = f.length; i--;)
{
f[i] = imageFactory(f[i]);
}
}
> function refr() {
> ++t;
> if (t >= f.length) t=0;
Inefficient operation; as you initialize with 0, and increment by 1,
only `>' is needed. However, I would not use a global variable here:
function refr(img, intv, t)
{
var me = arguments.callee;
if (typeof me.target == "undefined")
{
// or: !jsx.object.getFeature("document", "images", "pic")
if (typeof document == "undefined"
|| typeof document.images == "undefined"
|| typeof document.images[imgName] == "undefined"
|| typeof (me.target = document.images[imgName]).src
== "undefined")
{
return false;
}
}
if (typeof t == "undefined") t = -1;
++t;
img.src = (typeof f[t].src != "undefined" ? f[t].src : f[t]);
if (typeof window != "undefined"
&& jsx.object.isMethod(window, "setTimeout"))
{
window.setTimeout(function() { me(img, intv, t); }, intv * 1000);
}
}
In fact, all slides could be defined as properties of the animation method
so as to minimize the use of global variables. Then again, one would
consider using a slideshow object in the first place.
var slideshow = {
slides: [
{uri: ..., specialDelay: 0.5},
...
],
start: 0,
delay: 1.0,
run: function() {
// this.slides, this.start, this.current, this.delay
}
};
<body onload="slideshow.run('pic', 1.5)">
> document.images['pic'].src = f[t].src;
Untested property access (Reference Worm).
> setTimeout('refr()', interval * 1000);
Untested method call, relying on more error-prone scope chain resolution.
> }
> </script>
> </head>
> <body onLoad="setTimeout('refr()', interval * 1000);">
<body onload="refr('pic', 1.5);">
PointedEars
Thomas 'PointedEars' Lahn
> Bart Van der Donck wrote:
>> function refr() {
>> ++t;
>> if (t >= f.length) t=0;
>
> Inefficient operation; as you initialize with 0, and increment by 1,
> only `>' is needed. However, I would not use a global variable here:
>
> function refr(img, intv, t)
Argh, that refactoring devil!
function refr(imgName, intv, t)
> {
> var me = arguments.callee;
> [...]
> img.src = (typeof f[t].src != "undefined" ? f[t].src : f[t]);
me.target.src = (typeof f[t].src != "undefined" ? f[t].src : f[t]);
> [...]
> }
> [...]
PointedEars
Bart Van der Donck
> Bart Van der Donck wrote:
>
>> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
>> "http://www.w3.org/TR/html4/loose.dtd">
>> <html>
>> <head>
>> <title>Slideshow</title>
>> <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
>> <script type="text/javascript">
>> var interval = 1.5; // in seconds
>> var t = 0;
>
> Unnecessary global variables.
Misconception: 't' is necessarily global here. The value of 'interval'
could indeed be hardcoded, but IMHO it is more important that the OP
can put the desired seconds in a variable in the beginning of the
code. You win adaptability, transparency and maintainability with
that. You lose the memory of one single variable, which is
insignificant. Your descision which path to walk.
>> var f = new Array();
>> f[0] = new Image();
>
> Untested construction of host object.
But these tests are not necessary at all. Both Image and Array have
been supported since javascript 1.1:
http://devedge-temp.mozilla.org/library/manuals/2000/javascript/1.3/reference/image.html
http://docs.sun.com/source/816-6408-10/array.htm
>> f[0].src = 'http://216.92.6.95/app_pics/large/kCAm14d1JNRM7vn.jpg';
>> f[1] = new Image();
>> f[1].src = 'http://216.92.6.95/app_pics/large/YQk8ePvHibk19W6.jpg';
>> f[2] = new Image();
>> f[2].src = 'http://216.92.6.95/app_pics/large/H3rmiFJw3MheUaC.jpg';
>
> Unnecessary, harder-to-maintain assignments.
>
> var f = [
> "http://216.92.6.95/app_pics/large/kCAm14d1JNRM7vn.jpg",
> "http://216.92.6.95/app_pics/large/YQk8ePvHibk19W6.jpg",
> "http://216.92.6.95/app_pics/large/H3rmiFJw3MheUaC.jpg"
> ];
That is not the same. Your 'f' is an array of strings; my 'f' is an
array of objects.
> // or: jsx.object.isMethod(jsx.global, "Image"))
> var t = typeof Image;
> if (/^\s*unknown\s*/i.test(t)
> || /^\s*(function|object)\s*$/i.test(t) && Image)
> {
> var imageFactory = function(uri) {
> var img = new Image();
> img.src = uri;
> return img;
> };
>
> for (var i = f.length; i--;)
> {
> f[i] = imageFactory(f[i]);
> }
> }
>
>> function refr() {
>> ++t;
>> if (t >= f.length) t=0;
>
> Inefficient operation; as you initialize with 0, and increment by 1,
> only `>' is needed.
Nope. Try to run the code with '>' in stead of '>='. It errors out at
the point where both values are equal. You could use '=='.
> However, I would not use a global variable here:
>
> function refr(img, intv, t)
> {
> var me = arguments.callee;
>
> if (typeof me.target == "undefined")
> {
> // or: !jsx.object.getFeature("document", "images", "pic")
> if (typeof document == "undefined"
> || typeof document.images == "undefined"
> || typeof document.images[imgName] == "undefined"
> || typeof (me.target = document.images[imgName]).src
> == "undefined")
> {
> return false;
> }
> }
>
> if (typeof t == "undefined") t = -1;
> ++t;
>
> img.src = (typeof f[t].src != "undefined" ? f[t].src : f[t]);
>
> if (typeof window != "undefined"
> && jsx.object.isMethod(window, "setTimeout"))
See last paragraph.
> {
> window.setTimeout(function() { me(img, intv, t); }, intv * 1000);
> }
> }
>
> In fact, all slides could be defined as properties of the animation method
> so as to minimize the use of global variables. Then again, one would
> consider using a slideshow object in the first place.
>
> var slideshow = {
> slides: [
> {uri: ..., specialDelay: 0.5},
> ...
> ],
> start: 0,
> delay: 1.0,
>
> run: function() {
> // this.slides, this.start, this.current, this.delay
> }
> };
>
> <body onload="slideshow.run('pic', 1.5)">
My function counts four readable lines of code. Your code is at least
ten times longer, does not add any advantages and reads as a Kafka-
novel (you even had to correct yourself twice afterwards, which I
perfectly understand).
>> document.images['pic'].src = f[t].src;
>
> Untested property access (Reference Worm).
>
>> setTimeout('refr()', interval * 1000);
>
> Untested method call, relying on more error-prone scope chain resolution.
There are cases where feature detection is useful, but here it would
simply be silly. 'setTimeout' is supported since javascript 1.0 and
'document.images' since 1.1:
https://developer.mozilla.org/en/window.setTimeout
http://docs.sun.com/source/816-6408-10/document.htm
--
Bart
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> Bart Van der Donck wrote:
>>> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
>>> "http://www.w3.org/TR/html4/loose.dtd">
>>> <html>
>>> <head>
>>> <title>Slideshow</title>
>>> <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
>>> <script type="text/javascript">
>>> var interval = 1.5; // in seconds
>>> var t = 0;
>> Unnecessary global variables.
>
> Misconception: 't' is necessarily global here.
No, as I have demonstrated.
> The value of 'interval' could indeed be hardcoded, but IMHO it is more
> important that the OP can put the desired seconds in a variable in the
> beginning of the code. You win adaptability, transparency and
> maintainability with that. You lose the memory of one single variable,
> which is insignificant. Your descision which path to walk.
I will grant you that a variable serves transparency; however, sufficient
inline documentation of a property or method (JSdoc), or a property of a
object which reference is passed as argument to the method can do the same.
When avoiding global variables, it is of course not the memory they would
occupy that counts, but the side-effects they would create. And
maintainability is best served if a value does not have to be looked for
in two or more places.
>>> var f = new Array();
>>> f[0] = new Image();
>> Untested construction of host object.
>
> But these tests are not necessary at all.
The test of `Image' being [[Construct]]able is certainly necessary.
However, only its [[Call]]ability can be determined with probability
*and* compatibility.
> Both Image and Array have
> been supported since javascript 1.1:
> http://devedge-temp.mozilla.org/library/manuals/2000/javascript/1.3/reference/image.html
> http://docs.sun.com/source/816-6408-10/array.htm
You are referring to outdated information. The currently more widely
implemented JavaScript versions are 1.5 and higher. Since JavaScript 1.4
(effectively 1.5), when Client-side JavaScript went Core JavaScript and
Gecko DOM, `Image' is no longer officially part of the programming language.
Inofficially it never was, as JavaScript was bound to Netscape Mavigator
until then. And there are other ECMAScript implementations, most notably
Microsoft JScript, to which none of the above applies, and thus nothing can
be taken for granted about the runtime environment in which they are used.
As for Array(), I never said that it needed testing; in contrast, `Array'
does _not_ refer to a host object, is specified in ECMAScript, and still
part of its implementations.
>>> f[0].src = 'http://216.92.6.95/app_pics/large/kCAm14d1JNRM7vn.jpg';
>>> f[1] = new Image();
>>> f[1].src = 'http://216.92.6.95/app_pics/large/YQk8ePvHibk19W6.jpg';
>>> f[2] = new Image();
>>> f[2].src = 'http://216.92.6.95/app_pics/large/H3rmiFJw3MheUaC.jpg';
>> Unnecessary, harder-to-maintain assignments.
>>
>> var f = [
>> "http://216.92.6.95/app_pics/large/kCAm14d1JNRM7vn.jpg",
>> "http://216.92.6.95/app_pics/large/YQk8ePvHibk19W6.jpg",
>> "http://216.92.6.95/app_pics/large/H3rmiFJw3MheUaC.jpg"
>> ];
>
> That is not the same. Your 'f' is an array of strings; my 'f' is an
> array of objects.
Look closer below.
>> // or: jsx.object.isMethod(jsx.global, "Image"))
>> var t = typeof Image;
>> if (/^\s*unknown\s*/i.test(t)
>> || /^\s*(function|object)\s*$/i.test(t) && Image)
>> {
>> var imageFactory = function(uri) {
>> var img = new Image();
>> img.src = uri;
>> return img;
>> };
>>
>> for (var i = f.length; i--;)
>> {
>> f[i] = imageFactory(f[i]);
>> }
Here the array of string values becomes an array of Image object references
if supported.
>> }
>>
>>> function refr() {
>>> ++t;
>>> if (t >= f.length) t=0;
>> Inefficient operation; as you initialize with 0, and increment by 1,
>> only `>' is needed.
>
> Nope. Try to run the code with '>' in stead of '>='. It errors out at
> the point where both values are equal. You could use '=='.
if (t > f.length - 1)
works fine.
[implemented correction <news:4A3E5786...@PointedEars.de>]
>> However, I would not use a global variable here:
>>
>> function refr(img, intv, t)
>> {
>> [...]
>> me.target.src = (typeof f[t].src != "undefined" ? f[t].src : f[t]);
There is the precaution so that this works even if `Image' is unsupported.
>> if (typeof window != "undefined"
>> && jsx.object.isMethod(window, "setTimeout"))
>
> See last paragraph.
window.setTimeout(), too, is a host object's method, as `window' refers to a
host object. They always did.
>> {
>> window.setTimeout(function() { me(img, intv, t); }, intv * 1000);
>> }
>> }
>>
>> In fact, all slides could be defined as properties of the animation method
>> so as to minimize the use of global variables. Then again, one would
>> consider using a slideshow object in the first place.
>>
>> var slideshow = {
>> slides: [
>> {uri: ..., specialDelay: 0.5},
>> ...
>> ],
>> start: 0,
>> delay: 1.0,
>>
>> run: function() {
>> // this.slides, this.start, this.current, this.delay
>> }
>> };
>>
>> <body onload="slideshow.run('pic', 1.5)">
>
> My function counts four readable lines of code. Your code is at least
> ten times longer,
Maybe so.
> does not add any advantages
Yes, it does add considerable advantages, such as not breaking when exposed
to an unknown environment, reducing global variables, and eventually
encapsulating everying in *one* object.
> and reads as a Kafka-novel
Feature-testing and Object/Array initializers are common programming
techniques today. Of course, the feature-testing would be moved into a
library, as indicated by the single-line comments. After that, the
developer is left with only up to two lines of very easily legible code.
> (you even had to correct yourself twice afterwards,
No, I corrected myself one time in two places of the same code.
> which I perfectly understand).
Rest assured that you don't. Refactoring one's finished code (for getting
maximum efficiency out of it) sometimes carries with it the risk that
changes are not made in all necessary places, especially when that activity
takes place within a newsreader's editor instead of an IDE.
>>> document.images['pic'].src = f[t].src;
>> Untested property access (Reference Worm).
>>
>>> setTimeout('refr()', interval * 1000);
>> Untested method call, relying on more error-prone scope chain resolution.
>
> There are cases where feature detection is useful, but here it would
> simply be silly. 'setTimeout' is supported since javascript 1.0 and
> 'document.images' since 1.1:
> https://developer.mozilla.org/en/window.setTimeout
> http://docs.sun.com/source/816-6408-10/document.htm
Irrelevant documentation, see above for window.setTimeout();
document.images, too, refers to a host object; in W3C DOM-compliant
implementations, an object that implements the HTMLCollection interface.
PointedEars
Bart Van der Donck
> Bart Van der Donck wrote:
>> Thomas 'PointedEars' Lahn wrote:
>>> Bart Van der Donck wrote:
>>>> var interval = 1.5; // in seconds
>>>> var t = 0;
>>> Unnecessary global variables.
>> Misconception: 't' is necessarily global here.
> No, as I have demonstrated.
I see how it can be done when the number of seconds is harcoded. But
that was what I wanted to avoid (see previous), by working with a
configuration var in the beginning.
>> The value of 'interval' could indeed be hardcoded, but IMHO it is more
>> important that the OP can put the desired seconds in a variable in the
>> beginning of the code. You win adaptability, transparency and
>> maintainability with that. You lose the memory of one single variable,
>> which is insignificant. Your descision which path to walk.
>
> I will grant you that a variable serves transparency; however, sufficient
> inline documentation of a property or method (JSdoc), or a property of a
> object which reference is passed as argument to the method can do the same.
>
> When avoiding global variables, it is of course not the memory they would
> occupy that counts, but the side-effects they would create. And
> maintainability is best served if a value does not have to be looked for
> in two or more places.
That is certainly so... but how is this relevant here ?
>>>> var f = new Array();
>>>> f[0] = new Image();
>>> Untested construction of host object.
>
>> But these tests are not necessary at all.
>
> The test of `Image' being [[Construct]]able is certainly necessary.
> However, only its [[Call]]ability can be determined with probability
> *and* compatibility.
Let's see. Can you name a reasonable browser where 'var a = new Image
();' fails ?
I can't.
>> Both Image and Array have
>> been supported since javascript 1.1:
>> http://devedge-temp.mozilla.org/library/manuals/2000/javascript/1.3/r...
>> http://docs.sun.com/source/816-6408-10/array.htm
>
> You are referring to outdated information.
But I only wanted to backup my statement that Image and Array have
been supported since javascript 1.1. That information is not outdated
at all.
>>> [ snip code ]
>>>> if (t >= f.length) t=0;
>>> Inefficient operation; as you initialize with 0, and increment by 1,
>>> only `>' is needed.
>> Nope. Try to run the code with '>' in stead of '>='. It errors out at
>> the point where both values are equal. You could use '=='.
>
> if (t > f.length - 1)
> works fine.
Can't you see how absurd your comment is ??
I proposed
if (t == f.length)
and you want
if (t > f.length - 1)
:-)
>>> However, I would not use a global variable here:
>
>>> function refr(img, intv, t)
>>> {
>>> [...]
>>> me.target.src = (typeof f[t].src != "undefined" ? f[t].src : f[t]);
>
> There is the precaution so that this works even if `Image' is unsupported.
In which cases is the Image-object unsupported ?
> ...
> Feature-testing and Object/Array initializers are common programming
> techniques today.
Absolutely, but not Ex Absurdum. Your check 'if (typeof document ==
"undefined") {...' is absurdism in its most pure form.
> Of course, the feature-testing would be moved into a library, as
> indicated by the single-line comments.
That is a totally other thing. I don't agree, but let's not move into
that, please.
> After that, the developer is left with only up to two lines
> of very easily legible code.
Aha. You have a magic hat to make code disappear.
>> (you even had to correct yourself twice afterwards,
> No, I corrected myself one time in two places of the same code.
Which are two corrections.
>> There are cases where feature detection is useful, but here it would
>> simply be silly. 'setTimeout' is supported since javascript 1.0 and
>> 'document.images' since 1.1:
>> https://developer.mozilla.org/en/window.setTimeout
>> http://docs.sun.com/source/816-6408-10/document.htm
>
> Irrelevant documentation, see above for window.setTimeout();
https://developer.mozilla.org/en/window.setTimeout is not irrelevant
when you want to learn about setTimeout(). It should be your first
place to look.
--
Bart
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> Bart Van der Donck wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> Bart Van der Donck wrote:
>>>>> var interval = 1.5; // in seconds
>>>>> var t = 0;
>>>> Unnecessary global variables.
>>> Misconception: 't' is necessarily global here.
>> No, as I have demonstrated.
>
> I see how it can be done when the number of seconds is harcoded. But
> that was what I wanted to avoid (see previous), by working with a
> configuration var in the beginning.
As my code shows, it can be done without `t' being global *and* (what my
code doesn't show explicitly yet) without the number of seconds being
hardcoded. Watch for the Object initializer.
>>> The value of 'interval' could indeed be hardcoded, but IMHO it is more
>>> important that the OP can put the desired seconds in a variable in the
>>> beginning of the code. You win adaptability, transparency and
>>> maintainability with that. You lose the memory of one single variable,
>>> which is insignificant. Your descision which path to walk.
>> I will grant you that a variable serves transparency; however, sufficient
>> inline documentation of a property or method (JSdoc), or a property of a
>> object which reference is passed as argument to the method can do the same.
>>
>> When avoiding global variables, it is of course not the memory they would
>> occupy that counts, but the side-effects they would create. And
>> maintainability is best served if a value does not have to be looked for
>> in two or more places.
>
> That is certainly so... but how is this relevant here ?
The OP should not be presented with ill-advised code.
>>>>> var f = new Array();
>>>>> f[0] = new Image();
>>>> Untested construction of host object.
>>> But these tests are not necessary at all.
>> The test of `Image' being [[Construct]]able is certainly necessary.
>> However, only its [[Call]]ability can be determined with probability
>> *and* compatibility.
>
> Let's see. Can you name a reasonable browser where 'var a = new Image
> ();' fails ?
> I can't.
That does not mean anything.
>>> Both Image and Array have
>>> been supported since javascript 1.1:
>>> http://devedge-temp.mozilla.org/library/manuals/2000/javascript/1.3/r...
>>> http://docs.sun.com/source/816-6408-10/array.htm
>> You are referring to outdated information.
>
> But I only wanted to backup my statement that Image and Array have
> been supported since javascript 1.1. That information is not outdated
> at all.
Yes, it is, regarding `Image' (will you please drop `Array' now? I have
never said that it needed to be feature-tested anymore!). When a feature,
(here: Image) is not part of a programming language (here: JavaScript) since
more than a century, documentation that claims its availability is obsolete
regarding a discussion that is based on current versions of said programming
language.
Go to <https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference>;
you will find no `Image' object there, and rightly so.
>>>> [ snip code ]
>>>>> if (t >= f.length) t=0;
>>>> Inefficient operation; as you initialize with 0, and increment by 1,
>>>> only `>' is needed.
>>> Nope. Try to run the code with '>' in stead of '>='. It errors out at
>>> the point where both values are equal. You could use '=='.
>> if (t > f.length - 1)
>> works fine.
>
> Can't you see how absurd your comment is ??
No. I proposed using `>' instead of `>='.
> I proposed
> if (t == f.length)
> and you want
> if (t > f.length - 1)
>
> :-)
Your new proposition is arguably more efficient than your previous one,
but neither as safe, nor safer or more efficient than mine.
>>>> However, I would not use a global variable here:
>>>> function refr(img, intv, t)
>>>> {
>>>> [...]
>>>> me.target.src = (typeof f[t].src != "undefined" ? f[t].src : f[t]);
>> There is the precaution so that this works even if `Image' is unsupported..
>
> In which cases is the Image-object unsupported ?
See above.
>> ...
>> Feature-testing and Object/Array initializers are common programming
>> techniques today.
>
> Absolutely, but not Ex Absurdum. Your check 'if (typeof document ==
> "undefined") {...' is absurdism in its most pure form.
How so? `document' is either a property of a host object in the scope
chain, or a host-defined property of the Global Object since more than a
century; its availability depends on the host environment, and not on the
language version.
>> Of course, the feature-testing would be moved into a library, as
>> indicated by the single-line comments.
>
> That is a totally other thing.
It isn't. You said, in essence, that the code was hard to read; I pointed
out that, ignoring the subjectiveness of "hard", that code wouldn't be hard
to read if it was generalized as described. Whether or not the location of
the generalized code would be within a library or not does not even matter
for this. However, it stands to reason that feature-testing is that common
a task, and the approach likely subject to changes, that it should not be
simply copy-pasted as is; one or more external script resources, commonly
called script library/libraries, can provide that.
> I don't agree,
I am not surprised. You would rather continue writing error-prone code in
order to avoid feature-testing code that you do not understand, yes?
> but let's not move into that, please.
You started it, you have to live with it.
>> After that, the developer is left with only up to two lines
>> of very easily legible code.
>
> Aha. You have a magic hat to make code disappear.
No, the code would not disappear completely. However, it disappears from
the user code.
>>> (you even had to correct yourself twice afterwards,
>> No, I corrected myself one time in two places of the same code.
>
> Which are two corrections.
Quibbling over words. I corrected myself only once.
>>> There are cases where feature detection is useful, but here it would
>>> simply be silly. 'setTimeout' is supported since javascript 1.0 and
>>> 'document.images' since 1.1:
>>> https://developer.mozilla.org/en/window.setTimeout
>>> http://docs.sun.com/source/816-6408-10/document.htm
>> Irrelevant documentation, see above for window.setTimeout();
>
> https://developer.mozilla.org/en/window.setTimeout is not irrelevant
> when you want to learn about setTimeout(). It should be your first
> place to look.
You will observe that this article is located correctly under "Gecko DOM
Reference" and not "JavaScript Reference". The canonical URI is
<https://developer.mozilla.org/en/DOM/window.setTimeout>.
However, its Compatibility section is misleading regarding its JavaScript
version information, and wrong regarding its MSHTML version information.
That is unsurprising as MDC is a Wiki, and few people know how to
differentiate between the programming languages, and the APIs (like DOMs)
that can be used with them. I shall endeavour to correct the article in due
course.
PointedEars
Bart Van der Donck
> ...
> The OP should not be presented with ill-advised code.
But I did not present such code. IMHO the original poster received a
workable example of good quality.
>>> The test of `Image' being [[Construct]]able is certainly necessary.
>>> However, only its [[Call]]ability can be determined with probability
>>> *and* compatibility.
>
>> Let's see. Can you name a reasonable browser where 'var a = new Image
>> ();' fails ? I can't.
>
> That does not mean anything.
Okay, let me name you one then: the ancient Netscape Navigator 2.01.
from 1995 - I just tested. The question remains: which reasonable
browser would fail to execute 'var a = new Image();' ?
>> But I only wanted to backup my statement that Image and Array have
>> been supported since javascript 1.1. That information is not outdated
>> at all.
>
> Yes, it is, regarding `Image' (will you please drop `Array' now? I have
> never said that it needed to be feature-tested anymore!). When a feature,
> (here: Image) is not part of a programming language (here: JavaScript) since
> more than a century, documentation that claims its availability is obsolete
> regarding a discussion that is based on current versions of said programming
> language.
Empty over-theorising. It is simply no problem to use the Image-
object.
> Go to <https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference>;
> you will find no `Image' object there, and rightly so.
It's not in the 1.4 reference either
http://devedge-temp.mozilla.org/library/manuals/2000/javascript/1.4/reference/
Your observation is correct, your conclusion is wrong.
>> I proposed
>> if (t == f.length)
>> and you want
>> if (t > f.length - 1)
>> :-)
>
> Your new proposition is arguably more efficient than your previous one,
> but neither as safe, nor safer or more efficient than mine.
Bla bla bla. A construction 'if (t == f.length)' is much better than
'if (t > f.length - 1)' on all aspects.
>> In which cases is the Image-object unsupported ?
> See above.
Netscape Navigator 2.01. ?
>>> Feature-testing and Object/Array initializers are common programming
>>> techniques today.
>
>> Absolutely, but not Ex Absurdum. Your check 'if (typeof document ==
>> "undefined") {...' is absurdism in its most pure form.
>
> How so? `document' is either a property of a host object in the scope
> chain, or a host-defined property of the Global Object since more than a
> century; its availability depends on the host environment, and not on the
> language version.
Utterly absurd!
Check http://www.google.com/search?q=javascript+document
Which of the 17.600.000 results uses feature-detecting on 'document'
before invoking it ?
> [...]
> You would rather continue writing error-prone code in
> order to avoid feature-testing code that you do not understand, yes?
You know I am an advocate of feature detection - I'm using it all the
time - but not in absurd cases like this. Image objects have been
around since js 1.1. and are extremely unlikely to disappear towards
the future.
>>>> (you even had to correct yourself twice afterwards,
>>> No, I corrected myself one time in two places of the same code.
>> Which are two corrections.
> Quibbling over words. I corrected myself only once.
http://groups.google.com/group/comp.lang.javascript/msg/43f858ae2ceb5bed
You corrected
function refr(img, intv, t)
into
function refr(imgName, intv, t)
and you corrected
img.src = (typeof f[t].src != "undefined" ? f[t].src : f[t]);
into
me.target.src = (typeof f[t].src != "undefined" ? f[t].src : f[t]);
I can count. You can count. That are two corrections.
--
Bart
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>
> But I did not present such code. IMHO the original poster received a
> workable example of good quality.
IYHO.
>>>> The test of `Image' being [[Construct]]able is certainly necessary.
>>>> However, only its [[Call]]ability can be determined with probability
>>>> *and* compatibility.
>>> Let's see. Can you name a reasonable browser where 'var a = new Image
>>> ();' fails ? I can't.
>> That does not mean anything.
>
> Okay, let me name you one then: the ancient Netscape Navigator 2.01.
> from 1995 - I just tested. The question remains: which reasonable
> browser would fail to execute 'var a = new Image();' ?
You still miss the point.
>>> But I only wanted to backup my statement that Image and Array have
>>> been supported since javascript 1.1. That information is not outdated
>>> at all.
>> Yes, it is, regarding `Image' (will you please drop `Array' now? I have
>> never said that it needed to be feature-tested anymore!). When a feature,
>> (here: Image) is not part of a programming language (here: JavaScript) since
>> more than a century, documentation that claims its availability is obsolete
>> regarding a discussion that is based on current versions of said programming
>> language.
>
> Empty over-theorising.
Not at all.
> It is simply no problem to use the Image-object.
That remains to be seen. I am working on it.
>> Go to <https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference>;
>> you will find no `Image' object there, and rightly so.
>
> It's not in the 1.4 reference either
> http://devedge-temp.mozilla.org/library/manuals/2000/javascript/1.4/reference/
I think I have said that before. Nevertheless, as I indicated before, too,
JavaScript 1.4 is not a good example because it has never been implemented
client-side. So I chose the next implemented version for the comparison.
> Your observation is correct, your conclusion is wrong.
No. Your arguments are based on wishful thinking.
>>> I proposed
>>> if (t == f.length)
>>> and you want
>>> if (t > f.length - 1)
>>> :-)
>> Your new proposition is arguably more efficient than your previous one,
>> but neither as safe, nor safer or more efficient than mine.
>
> Bla bla bla.
Very eloquent.
> A construction 'if (t == f.length)' is much better than
> 'if (t > f.length - 1)' on all aspects.
No, it is not. To begin with, `==' does some unnecessary type checks, and
let's the script break if one decides to increment by more than one. You
would have known if you knew what you are talking about and had read the
ECMAScript Language Specification, Edition 3 Final, sections 11.9.1 and
11.9.3, or simply performed a few tests.
>>> In which cases is the Image-object unsupported ?
>> See above.
>
> Netscape Navigator 2.01. ?
Probably yes. Hardly relevant nowadays, though.
>>>> Feature-testing and Object/Array initializers are common programming
>>>> techniques today.
>>> Absolutely, but not Ex Absurdum. Your check 'if (typeof document ==
>>> "undefined") {...' is absurdism in its most pure form.
>> How so? `document' is either a property of a host object in the scope
>> chain, or a host-defined property of the Global Object since more than a
>> century; its availability depends on the host environment, and not on the
>> language version.
>
> Utterly absurd!
> Check http://www.google.com/search?q=javascript+document
> Which of the 17.600.000 results uses feature-detecting on 'document'
> before invoking it ?
You're right, we really should eat shit. A million flies can't be wrong.
>> [...]
>> You would rather continue writing error-prone code in
>> order to avoid feature-testing code that you do not understand, yes?
>
> You know I am an advocate of feature detection - I'm using it all the
> time - but not in absurd cases like this. Image objects have been
> around since js 1.1.
Again, it does not matter what the language version was when (not: if) the
feature is no longer part of the language since more than a century. The
earlier you get this, the earlier you will be writing scripts that do not
break when exposed to a previously unknown environment.
> and are extremely unlikely to disappear towards the future.
We'll see. For example, it stands to reason that a user agent that does
not show images but implements ECMAScript does not need to provide Image
objects.
PointedEars
Erwin Moller
>>>>> Feature-testing and Object/Array initializers are common programming
>>>>> techniques today.
>>>> Absolutely, but not Ex Absurdum. Your check 'if (typeof document ==
>>>> "undefined") {...' is absurdism in its most pure form.
>>> How so? `document' is either a property of a host object in the scope
>>> chain, or a host-defined property of the Global Object since more than a
>>> century; its availability depends on the host environment, and not on the
>>> language version.
>> Utterly absurd!
>> Check http://www.google.com/search?q=javascript+document
>> Which of the 17.600.000 results uses feature-detecting on 'document'
>> before invoking it ?
>
> You're right, we really should eat shit. A million flies can't be wrong.
Hi all,
Is PointedEars advising to always feature-detect the document-object
before using it?
With all due respect for PointedEars from whom I learned a lot in the
past, and I am sure that reading PointedEars' posting made me a better
JavaScript/DOM programmer, BUT isn't this a little over the top?
Why should one test for the existance of document if you are delivering
content for webbrowsers?
If I let the server return a HTML-page to the browser, how can there be
no document on the clientside (broken browser not taking into account)?
Why test?
Maybe I am totally missing the point here, so please explain it slowly
to me. ;-)
Regards,
Erwin Moller
--
"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult."
-- C.A.R. Hoare
Thomas 'PointedEars' Lahn
> Again, it does not matter what the language version was when (not: if) the
Err, _decade_. But it was in the last century :)
PointedEars
Bart Van der Donck
> Bart Van der Donck wrote:
>
>> It is simply no problem to use the Image-object.
> That remains to be seen. I am working on it.
I am curious.
>> A construction 'if (t == f.length)' is much better than
>> 'if (t > f.length - 1)' on all aspects.
>
> No, it is not. To begin with, `==' does some unnecessary type checks, and
> let's the script break if one decides to increment by more than one.
It's not possible that variable 't' is incremented by more than 1 in
the code in question. And you know that.
The essence is simple. We agree that 'if (t == f.length)' does the
job. It is simply absurd to propose 'if (t > f.length - 1)' then as an
alternative because of (cit.) "some unnecessary type checks of ==". If
you want to check whether 2 numerical values are equal, then use
'==' !
>>>> In which cases is the Image-object unsupported ?
>>> See above.
>> Netscape Navigator 2.01. ?
> Probably yes. Hardly relevant nowadays, though.
Understatement. There is no need to be compatible with Netscape
Navigator 2.01. nowadays (javascript 1.0.).
>> Utterly absurd!
>> Check http://www.google.com/search?q=javascript+document
>> Which of the 17.600.000 results uses feature-detecting on 'document'
>> before invoking it ?
>
> You're right, we really should eat shit. A million flies can't be wrong.
I am not a fly; so your metaphor is invalid. Your advice to feature-
detect on 'document' is simply hilarious.
> We'll see. For example, it stands to reason that a user agent that does
> not show images but implements ECMAScript does not need to provide Image
> objects.
Of course it is theoretically possible to build such a (cit.) "user
agent that does not show images". But such a browser would be
absolutely unsuitable for normal use.
--
Bart
David Mark
[snip]
> Of course it is theoretically possible to build such a (cit.) "user
> agent that does not show images". But such a browser would be
> absolutely unsuitable for normal use.
>
It's been done (e.g Lynx.) It's perfectly suitable for uses that
might not be considered "normal." For one, text-based browsers are
useful to connect to speech synthesizers for the blind. Granted the
Web is such a semantic catastrophe that most sites will read as random
gibberish.
Of course, AFAIK, Lynx has never supported scripting, but you never
know what the future might hold. A scripted text-only browser is not
a stretch IMO and I wouldn't expect it to construct Image objects.
Exceptions that halt scripts unexpectedly lead to unusable documents
(progressive destruction.)
As for detecting the document object, that is a stretch if your script
is strictly for Web browsers. But it's not as if such strict testing
would clutter code as in production (as opposed to examples) it is
virtually always encapsulated in functions (at least for those who
wish to avoid maintaining Kafka-esque code.)
Conrad Lender
> Of course, AFAIK, Lynx has never supported scripting, but you never
> know what the future might hold. A scripted text-only browser is not
> a stretch IMO and I wouldn't expect it to construct Image objects.
> Exceptions that halt scripts unexpectedly lead to unusable documents
> (progressive destruction.)
Both w3m and elinks have rudimentary script support. I don't have the
w3m-js version installed, so can't test, but I do have a JS-enabled
elinks. It uses the SpiderMonkey library, which should be relatively
current regarding ECMAScript features. DOM and host features is another
matter: alert() works, document.write() doesn't and - to prove your
point - Image doesn't.
- Conrad
Thomas 'PointedEars' Lahn
Why, *his* point? ;-) Anyhow, thanks for the tests. I had already started
on a posting saying about the same when an Eclipse update became necessary;
however, I will nevertheless try to confirm your results before they go into
the DOM Support Matrix¹. To that end, which versions of w3m and ELinks have
you tested with?
TIA
PointedEars
Conrad Lender
> Conrad Lender wrote:
>> Both w3m and elinks have rudimentary script support. I don't have
>> the w3m-js version installed, so can't test, but I do have a
>> JS-enabled elinks. It uses the SpiderMonkey library, which should
>> be relatively current regarding ECMAScript features. DOM and host
>> features is another matter: alert() works, document.write() doesn't
>> and - to prove your point - Image doesn't.
>
> Why, *his* point? ;-) Anyhow, thanks for the tests. I had already
> started on a posting saying about the same when an Eclipse update
> became necessary; however, I will nevertheless try to confirm your
> results before they go into the DOM Support Matrix¹. To that end,
> which versions of w3m and ELinks have you tested with?
w3m: not tested,
elinks: 0.12pre4, built from source with libmozjs-dev 1.8.1.18
JavaScript features (up to 1.6) are well supported, but I couldn't get
anything from 1.7 or 1.8 to work (scripts with the MIME type
"application/javascript,version=1.x" aren't executed). The typical
browser environment and the DOM is practically nonexistent
(window.location and document are available, but no document.gEBI,
document.documentElement, etc). At this point, I'd say browser scripting
in elinks is not in any usable state. It's an interesting step for a
text browser, but supporting JavaScript in a browser takes a bit more
than just including SpiderMonkey.
As an aside, depending on the terminal and configuration, both w3m and
elinks can display inline images. Gave me a bit of a shock when I first
saw it :-)
- Conrad
David Mark
wrote:
> Conrad Lender wrote:
> > On 24/06/09 09:59, David Mark wrote:
> >> Of course, AFAIK, Lynx has never supported scripting, but you never
> >> know what the future might hold. A scripted text-only browser is not
> >> a stretch IMO and I wouldn't expect it to construct Image objects.
> >> Exceptions that halt scripts unexpectedly lead to unusable documents
> >> (progressive destruction.)
>
> > Both w3m and elinks have rudimentary script support. I don't have the
> > w3m-js version installed, so can't test, but I do have a JS-enabled
> > elinks. It uses the SpiderMonkey library, which should be relatively
> > current regarding ECMAScript features. DOM and host features is another
> > matter: alert() works, document.write() doesn't and - to prove your
> > point - Image doesn't.
>
> Why, *his* point? ;-) Anyhow, thanks for the tests.
You get credit for an assist.
David Mark
How can you learn the language studying code that relies on dubious
libraries. Are they to wade through jQuery and Prototype (or
whatever) to get to the bottom of it? Those are pretty bad examples
of both Javascript and browser scripting. I suppose if you want to
learn what not to do, but that's the long way around.
JR
> > I'd like to suggest that you learn Javascript as soon as possible
> > because it would improve your skills in web development. Besides
> > reading recommended books (http://www.jibbering.com/faq/#books), a
> > complementary way to learn any language is studying other developer's
> > code. This is why I suggest studying these two libraries: Lightbox and
> > Highslide (Google for these names), although they require other
> > libraries to work properly.
> How can you learn the language studying code that relies on dubious
> libraries. Are they to wade through jQuery and Prototype (or
> whatever) to get to the bottom of it? Those are pretty bad examples
> of both Javascript and browser scripting. I suppose if you want to
> learn what not to do, but that's the long way around.
Learning from the code of other developers is never invalid, even in
the case of bad code. Just like medical students dissect dead bodies
before working as doctors, programming students need to study codes
from other developers before becoming good developers. However some
developers prefer to make 'autopsy' most of the time, dissecting
jQuery for example...
I think this guy, John Resig, is a very clever man, because he really
knows how to put in practice many of the "laws of Power" (http://
www2.tech.purdue.edu/cg/Courses/cgt411/covey/48_laws_of_power.htm),
e.g.:
Law 2 - Never put too much trust in Friends, learn how to use
Enemies. [Every time you post a bug in jQuery, I bet John Resig
receives that input].
Law 6 - Court Attention at all Cost.
Law 7 - Get others to do the Work for you, but Always Take the
Credit. [John Resig is a Master on this one]
Law 11 - Learn to Keep People Dependent on You.
Law 13 - When Asking for Help, Appeal to People’s Self-Interest, Never
to their Mercy or Gratitude.
Law 27 - Play on People’s Need to Believe to Create a Cultlike
Following (People have an overwhelming desire to believe in
something).
Law 31 - Control the Options: Get Others to Play with the Cards you
Deal.
Law 37 - Create Compelling Spectacles. [jQuery site?]
Cheers,
Joao Rodrigues
Richard Cornford
On Jun 24, 8:31 pm, David Mark wrote:
>> How can you learn the language studying code that relies on
>> dubious libraries. Are they to wade through jQuery and
>> Prototype (or whatever) to get to the bottom of it? Those
>> are pretty bad examples of both Javascript and browser
>> scripting. I suppose if you want to learn what not to do,
>> but that's the long way around.
>
> Learning from the code of other developers is never invalid,
> even in the case of bad code.
It does seem important in that case to know whether, and why, bad code
is bad code. If it were mistaken for good then the 'learning' experience
is likely to be negative.
> Just like medical students
> dissect dead bodies before working as doctors,
Art students (not that many in practice but if you attend the right art
school you do get the choice) also dissect dead bodies as part of their
learning experience, but they don't become qualified as doctors as a
result of doing so.
> programming students need to study codes from other
> developers before becoming good developers.
Where before means 'at some time prior to ... ', and does not imply that
doing so will be all that is necessary.
> However some developers prefer to
> make 'autopsy' most of the time, dissecting jQuery for
> example...
<snip>
Running with that analogy; on the JQuery mailing lists/groups you see a
fair number of copy-n-paste Frankenstein's monsters. Never pretty, and
not the products of "good developers".
Richard.
Richard Cornford
<snip>
> I think this guy, John Resig, is a very clever man, because
> he really knows how to put in practice many of the "laws of
> Power"
> (http://www2.tech.purdue.edu/cg/Courses/cgt411/covey/48_laws_of_power.htm),
> e.g.:
>
> Law 2 - Never put too much trust in Friends, learn how to use
> Enemies. [Every time you post a bug in jQuery, I bet John Resig
> receives that input].
> Law 6 - Court Attention at all Cost.
> Law 7 - Get others to do the Work for you, but Always Take the
> Credit. [John Resig is a Master on this one]
> Law 11 - Learn to Keep People Dependent on You.
> Never to their Mercy or Gratitude.
> Following (People have an overwhelming desire to believe in
> something).
> Law 31 - Control the Options: Get Others to Play with the Cards you
> Deal.
> Law 37 - Create Compelling Spectacles. [jQuery site?]
LOL. So you are calling John Resig a shyster. There has got to be a
phrase for this type of character assignation. Something along the same
lines as "damming with faint praise", but stronger (there is nothing
faint here).
Richard.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> Bart Van der Donck wrote:
>>> It is simply no problem to use the Image-object.
>> That remains to be seen. I am working on it.
>
> I am curious.
You will have to be patient like everyone else, but now that it has been
pointed out by others explicitly that there are real-existing user agents
that support scripting but not `Image', this should give you pause.
>>> A construction 'if (t == f.length)' is much better than
>>> 'if (t > f.length - 1)' on all aspects.
>> No, it is not. To begin with, `==' does some unnecessary type checks, and
>> let's the script break if one decides to increment by more than one.
>
> It's not possible that variable 't' is incremented by more than 1 in
> the code in question. And you know that.
I don't know what the OP will want to modify about this code and neither do
you. However, it is not good to forbid them this option by making the code
more inflexible than it needs to be.
> The essence is simple. We agree that 'if (t == f.length)' does the
> job.
No, we don't. To begin with, I'm inclined to use `===' nowadays.
> It is simply absurd to propose 'if (t > f.length - 1)' then as an
> alternative because of (cit.) "some unnecessary type checks of ==". If
> you want to check whether 2 numerical values are equal, then use
> '==' !
No and no.
>>>>> In which cases is the Image-object unsupported ?
>>>> See above.
>>> Netscape Navigator 2.01. ?
>> Probably yes. Hardly relevant nowadays, though.
>
> Understatement. There is no need to be compatible with Netscape
> Navigator 2.01. nowadays (javascript 1.0.).
True, however I don't think you understood what I meant.
>>> Utterly absurd!
>>> Check http://www.google.com/search?q=javascript+document
>>> Which of the 17.600.000 results uses feature-detecting on 'document'
>>> before invoking it ?
>> You're right, we really should eat shit. A million flies can't be wrong.
>
> I am not a fly; so your metaphor is invalid.
You are mistaken. The nature of a metaphor is that the subjects are
exchangeable within the boundaries of their relations. You propose that
because there may be many examples (many flies) where feature-detection is
not used there (eat shit; shit being a metaphor for bad code quality, of
course) it would be a good idea for us not to use it (eat shit, too).
(Several types of fallacies for this come to mind, including
proof-by-example.) And you know that.
> Your advice to feature-detect on 'document' is simply hilarious.
You are easily amused, but your ignorance does not mean anything
against the correctness of this approach. The record shows.
>> We'll see. For example, it stands to reason that a user agent that does
>> not show images but implements ECMAScript does not need to provide Image
>> objects.
>
> Of course it is theoretically possible to build such a (cit.) "user
> agent that does not show images". But such a browser would be
> absolutely unsuitable for normal use.
Again, your ignorance is irrelevant.
PointedEars
David Mark
> On Jun 24, 8:31 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > I'd like to suggest that you learn Javascript as soon as possible
> > > because it would improve your skills in web development. Besides
> > > reading recommended books (http://www.jibbering.com/faq/#books), a
> > > complementary way to learn any language is studying other developer's
> > > code. This is why I suggest studying these two libraries: Lightbox and
> > > Highslide (Google for these names), although they require other
> > > libraries to work properly.
> > How can you learn the language studying code that relies on dubious
> > libraries. Are they to wade through jQuery and Prototype (or
> > whatever) to get to the bottom of it? Those are pretty bad examples
> > of both Javascript and browser scripting. I suppose if you want to
> > learn what not to do, but that's the long way around.
>
> Learning from the code of other developers is never invalid, even in
> the case of bad code. Just like medical students dissect dead bodies
> before working as doctors, programming students need to study codes
> from other developers before becoming good developers. However some
> developers prefer to make 'autopsy' most of the time, dissecting
> jQuery for example...
As noted, that's nonsense. You don't study bad examples (unless you
know that they are bad and are seeking to learn how not to do things.)
>
> I think this guy, John Resig, is a very clever man, because he really
> knows how to put in practice many of the "laws of Power" (http://
> www2.tech.purdue.edu/cg/Courses/cgt411/covey/48_laws_of_power.htm),
> e.g.:
What's clever about him?
>
> Law 2 - Never put too much trust in Friends, learn how to use
> Enemies. [Every time you post a bug in jQuery, I bet John Resig
> receives that input].
How out of touch are you? If he does know of the bugs I've pointed
out, he's either too ignorant to understand them or too incompetent to
deal with them. How does that help him?
> Law 6 - Court Attention at all Cost.
I'd say most who've heard his name have heard mine by now. ;)
> Law 7 - Get others to do the Work for you, but Always Take the
> Credit. [John Resig is a Master on this one]
Like when he copies my code and ideas? Too bad he's so clumsy with
them he gets no points.
> Law 11 - Learn to Keep People Dependent on You.
Yeah, he's a cult leader.
> Law 13 - When Asking for Help, Appeal to People’s Self-Interest, Never
> to their Mercy or Gratitude.
Whatever.
> Law 27 - Play on People’s Need to Believe to Create a Cultlike
> Following (People have an overwhelming desire to believe in
> something).
See above.
> Law 31 - Control the Options: Get Others to Play with the Cards you
> Deal.
Not hardly.
> Law 37 - Create Compelling Spectacles. [jQuery site?]
Nothing compelling there.
Conrad Lender
> On Jun 24, 9:07 pm, JR <groups_j...@yahoo.com.br> wrote:
>> Law 2 - Never put too much trust in Friends, learn how to use
>> Enemies. [Every time you post a bug in jQuery, I bet John Resig
>> receives that input].
>
> How out of touch are you? If he does know of the bugs I've pointed
> out, he's either too ignorant to understand them or too incompetent to
> deal with them.
If you want those bugs fixed, file them in their bug tracker, instead of
posting your rants on reddit or in cljs. If you don't want them fixed,
stop complaining about them.
You got kicked from the JQuery user group twice in one day, so you may
want to tone down your complaints a bit, if you want to be taken
seriously. What are you doing in that kindergarden anyway, don't you
have more important things to do? Like fix Dojo or something?
> How does that help him?
Beats me.
- Conrad
David Mark
> On 28/06/09 05:37, David Mark wrote:
>
> > On Jun 24, 9:07 pm, JR <groups_j...@yahoo.com.br> wrote:
> >> Law 2 - Never put too much trust in Friends, learn how to use
> >> Enemies. [Every time you post a bug in jQuery, I bet John Resig
> >> receives that input].
>
> > How out of touch are you? If he does know of the bugs I've pointed
> > out, he's either too ignorant to understand them or too incompetent to
> > deal with them.
>
> If you want those bugs fixed, file them in their bug tracker, instead of
Why would I want them fixed? And besides, I've given very basic
fixes directly to John Resig and the problems persist to this day.
Not a good sign.
> posting your rants on reddit or in cljs. If you don't want them fixed,
Don't be stupid. First off, other people syndicate my stuff sites
like Reddit. Furthermore, this groups is about browser scripting,
which includes advice about fantasy code like jQuery. It's not about
fixing bugs, though it is ironic that the jQuery people refuse to read
it. That's *their* problem, not mine.
> stop complaining about them.
I don't need your advice on posting.
>
> You got kicked from the JQuery user group twice in one day, so you may
Not even close. I've never posted anything in the jQuery groups. I
doubt their idiotic moderator would let me anyway. What I did do was
to post two non-complaints under a generic name to illustrate their
relentless (and ridiculous) censorship. Both were good advice as
well, so who are the losers here?
> want to tone down your complaints a bit, if you want to be taken
See above. Never posted a complaint to those groups.
> seriously. What are you doing in that kindergarden anyway, don't you
Mind your own time.
> have more important things to do? Like fix Dojo or something?
And your own business.
>
> > How does that help him?
>
> Beats me.
That about sums it up.
Bart Van der Donck
> Bart Van der Donck wrote:
>
>> We agree that 'if (t == f.length)' does the job.
>
> No, we don't. To begin with, I'm inclined to use `===' nowadays.
Pardon ? I don't understand that you dare to use '===', and advocate
to feature-detect on 'document' at the same time. The chance that
'===' fails, is much, much higher.
>> If you want to check whether 2 numerical values are equal, then
>> use '==' !
>
> No and no.
As I repeated above, the code in question holds two operands of the
same type; so there is absolutely nothing wrong to use '=='.
>> Your advice to feature-detect on 'document' is simply hilarious.
>
> You are easily amused, but your ignorance does not mean anything
> against the correctness of this approach.
Which "ignorance" would that be ? The "ignorance" to not see that a
feature-test on 'document' is necessary ?
>> Of course it is theoretically possible to build such a (cit.) "user
>> agent that does not show images". But such a browser would be
>> absolutely unsuitable for normal use.
>
> Again, your ignorance is irrelevant.
No, it's only Realpolitik. Conrad's tests are interesting; but my
conclusion would be that it's a bit senseless to develop javascript in
such an environment (besides the academic excercise, perhaps). With
some effort and good will, I can see David's point to be compatible
with blind users. Lynx would appear irrelevant to me.
--
Bart
David Mark
> Thomas 'PointedEars' Lahn wrote:
> > Bart Van der Donck wrote:
>
> >> We agree that 'if (t == f.length)' does the job.
>
> > No, we don't. To begin with, I'm inclined to use `===' nowadays.
>
> Pardon ? I don't understand that you dare to use '===', and advocate
> to feature-detect on 'document' at the same time. The chance that
> '===' fails, is much, much higher.
In terms of scripts that run in browsers, I agree.
>
> >> If you want to check whether 2 numerical values are equal, then
> >> use '==' !
>
> > No and no.
>
> As I repeated above, the code in question holds two operands of the
> same type; so there is absolutely nothing wrong to use '=='.
Exactly. Using === for such cases obfuscates the code.
>
> >> Your advice to feature-detect on 'document' is simply hilarious.
>
> > You are easily amused, but your ignorance does not mean anything
> > against the correctness of this approach.
>
> Which "ignorance" would that be ? The "ignorance" to not see that a
> feature-test on 'document' is necessary ?
You are right as far as browser scripts go.
>
> >> Of course it is theoretically possible to build such a (cit.) "user
> >> agent that does not show images". But such a browser would be
> >> absolutely unsuitable for normal use.
>
> > Again, your ignorance is irrelevant.
>
> No, it's only Realpolitik. Conrad's tests are interesting; but my
> conclusion would be that it's a bit senseless to develop javascript in
> such an environment (besides the academic excercise, perhaps). With
> some effort and good will, I can see David's point to be compatible
> with blind users. Lynx would appear irrelevant to me.
None of that requires detection of the document object (in browsers.)
Thomas 'PointedEars' Lahn
> On Jul 1, 3:49 pm, Bart Van der Donck <b...@nijlen.com> wrote:
>> Thomas 'PointedEars' Lahn wrote:
>>> Bart Van der Donck wrote:
>>>> We agree that 'if (t == f.length)' does the job.
>>> No, we don't. To begin with, I'm inclined to use `===' nowadays.
>> Pardon ? I don't understand that you dare to use '===', and advocate
>> to feature-detect on 'document' at the same time. The chance that
>> '===' fails, is much, much higher.
>
> In terms of scripts that run in browsers, I agree.
I wonder, is there some *evidence* to support your opinion?
After discussion about `===' vs `==' here some time ago, I have included
`===' in the ECMAScript Support Matrix. It is documented to work since
JavaScript 1.3, JScript 1.0 (tests pending). It is tested to work since
JavaScript 1.3 (in NN 4.78). It works in Opera 5.02 and 9.52 (and probably
versions in-between too, tests pending), and Konqueror 3.5.9 (and probably
earlier, KJS source analysis and maybe tests pending).
So where does it fail?
>>>> If you want to check whether 2 numerical values are equal, then
>>>> use '==' !
>>> No and no.
>> As I repeated above, the code in question holds two operands of the
>> same type; so there is absolutely nothing wrong to use '=='.
>
> Exactly.
Yes, there is. Read the Spec.
> Using === for such cases obfuscates the code.
Rubbish.
>>>> Your advice to feature-detect on 'document' is simply hilarious.
>>> You are easily amused, but your ignorance does not mean anything
>>> against the correctness of this approach.
>> Which "ignorance" would that be ? The "ignorance" to not see that a
>> feature-test on 'document' is necessary ?
>
> You are right as far as browser scripts go.
Wishful thinking.
>>>> Of course it is theoretically possible to build such a (cit.) "user
>>>> agent that does not show images". But such a browser would be
>>>> absolutely unsuitable for normal use.
>>> Again, your ignorance is irrelevant.
>> No, it's only Realpolitik. Conrad's tests are interesting; but my
>> conclusion would be that it's a bit senseless to develop javascript in
>> such an environment (besides the academic excercise, perhaps). With
>> some effort and good will, I can see David's point to be compatible
>> with blind users. Lynx would appear irrelevant to me.
Lynx does not support scripting. ELinks does; to what extent current
versions do is currently unknown, unfortunately my current(?) prepackaged
"ELinks 0.11.4 (built on Sep 20 2008 16:08:30)" does not have script support
enabled.
> None of that requires detection of the document object (in browsers.)
Wishful thinking again. If that's all you have to say, I rest my case.
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300...@news.demon.co.uk>
David Mark
wrote:
> David Mark wrote:
> > On Jul 1, 3:49 pm, Bart Van der Donck <b...@nijlen.com> wrote:
> >> Thomas 'PointedEars' Lahn wrote:
> >>> Bart Van der Donck wrote:
> >>>> We agree that 'if (t == f.length)' does the job.
> >>> No, we don't. To begin with, I'm inclined to use `===' nowadays.
> >> Pardon ? I don't understand that you dare to use '===', and advocate
> >> to feature-detect on 'document' at the same time. The chance that
> >> '===' fails, is much, much higher.
>
> > In terms of scripts that run in browsers, I agree.
>
> I wonder, is there some *evidence* to support your opinion?
Yes.
>
> After discussion about `===' vs `==' here some time ago, I have included
> `===' in the ECMAScript Support Matrix. It is documented to work since
> JavaScript 1.3, JScript 1.0 (tests pending). It is tested to work since
> JavaScript 1.3 (in NN 4.78). It works in Opera 5.02 and 9.52 (and probably
> versions in-between too, tests pending), and Konqueror 3.5.9 (and probably
> earlier, KJS source analysis and maybe tests pending).
>
> So where does it fail?
In very old browsers, but that's beside the (main) point.
>
> >>>> If you want to check whether 2 numerical values are equal, then
> >>>> use '==' !
> >>> No and no.
> >> As I repeated above, the code in question holds two operands of the
> >> same type; so there is absolutely nothing wrong to use '=='.
>
> > Exactly.
>
> Yes, there is. Read the Spec.
Don't need to. There's nothing wrong with using == in this case.
>
> > Using === for such cases obfuscates the code.
>
> Rubbish.
Nope. First thing I would think on seeing === is that the two
operands could be different types. Using == makes the author's
intentions clear.
>
> >>>> Your advice to feature-detect on 'document' is simply hilarious.
> >>> You are easily amused, but your ignorance does not mean anything
> >>> against the correctness of this approach.
> >> Which "ignorance" would that be ? The "ignorance" to not see that a
> >> feature-test on 'document' is necessary ?
>
> > You are right as far as browser scripts go.
>
> Wishful thinking.
I wonder what usable browser would lack a document object. No
evidence to support that AFAIK.
>
> >>>> Of course it is theoretically possible to build such a (cit.) "user
> >>>> agent that does not show images". But such a browser would be
> >>>> absolutely unsuitable for normal use.
> >>> Again, your ignorance is irrelevant.
> >> No, it's only Realpolitik. Conrad's tests are interesting; but my
> >> conclusion would be that it's a bit senseless to develop javascript in
> >> such an environment (besides the academic excercise, perhaps). With
> >> some effort and good will, I can see David's point to be compatible
> >> with blind users. Lynx would appear irrelevant to me.
>
> Lynx does not support scripting. ELinks does; to what extent current
> versions do is currently unknown, unfortunately my current(?) prepackaged
> "ELinks 0.11.4 (built on Sep 20 2008 16:08:30)" does not have script support
> enabled.
>
> > None of that requires detection of the document object (in browsers.)
>
> Wishful thinking again. If that's all you have to say, I rest my case.
Then it's up to the jury I guess.
Thomas 'PointedEars' Lahn
> David Mark wrote:
>> On Jul 1, 3:49 pm, Bart Van der Donck <b...@nijlen.com> wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> Bart Van der Donck wrote:
>>>>> We agree that 'if (t == f.length)' does the job.
>>>> No, we don't. To begin with, I'm inclined to use `===' nowadays.
>>> Pardon ? I don't understand that you dare to use '===', and advocate
>>> to feature-detect on 'document' at the same time. The chance that
>>> '===' fails, is much, much higher.
>> In terms of scripts that run in browsers, I agree.
>
> I wonder, is there some *evidence* to support your opinion?
>
> After discussion about `===' vs `==' here some time ago, I have included
> `===' in the ECMAScript Support Matrix. It is documented to work since
> JavaScript 1.3, JScript 1.0 (tests pending).
Just tested: Works fine in JScript 5.1.5010 (IE/MSHTML 5.01, released in
1999). Do I need to go further back?
> It is tested to work since JavaScript 1.3 (in NN 4.78). It works in
> Opera 5.02 and 9.52 (and probably versions in-between too, tests
> pending), and Konqueror 3.5.9 (and probably earlier, KJS source analysis
> and maybe tests pending).
>
> So where does it fail?
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> Bart Van der Donck wrote:
>>> We agree that 'if (t == f.length)' does the job.
>> No, we don't. To begin with, I'm inclined to use `===' nowadays.
>
> Pardon ? I don't understand that you dare to use '===', and advocate
> to feature-detect on 'document' at the same time.
Yes, you don't appear to understand that different criteria must be applied
to a language feature, that is provided by the language implementation, and
a host feature, that is provided by the host environment.
> The chance that '===' fails, is much, much higher.
Nonsense.
David Mark
wrote:
> Thomas 'PointedEars' Lahn wrote:
> > David Mark wrote:
> >> On Jul 1, 3:49 pm, Bart Van der Donck <b...@nijlen.com> wrote:
> >>> Thomas 'PointedEars' Lahn wrote:
> >>>> Bart Van der Donck wrote:
> >>>>> We agree that 'if (t == f.length)' does the job.
> >>>> No, we don't. To begin with, I'm inclined to use `===' nowadays.
> >>> Pardon ? I don't understand that you dare to use '===', and advocate
> >>> to feature-detect on 'document' at the same time. The chance that
> >>> '===' fails, is much, much higher.
> >> In terms of scripts that run in browsers, I agree.
>
> > I wonder, is there some *evidence* to support your opinion?
>
> > After discussion about `===' vs `==' here some time ago, I have included
> > `===' in the ECMAScript Support Matrix. It is documented to work since
> > JavaScript 1.3, JScript 1.0 (tests pending).
>
> Just tested: Works fine in JScript 5.1.5010 (IE/MSHTML 5.01, released in
> 1999). Do I need to go further back?
>
> > It is tested to work since JavaScript 1.3 (in NN 4.78). It works in
> > Opera 5.02 and 9.52 (and probably versions in-between too, tests
> > pending), and Konqueror 3.5.9 (and probably earlier, KJS source analysis
> > and maybe tests pending).
>
> > So where does it fail?
I move for a mistrial.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> David Mark wrote:
>>> On Jul 1, 3:49 pm, Bart Van der Donck <b...@nijlen.com> wrote:
>>>> Thomas 'PointedEars' Lahn wrote:
>>>>> Bart Van der Donck wrote:
>>>>>> We agree that 'if (t == f.length)' does the job.
>>>>> No, we don't. To begin with, I'm inclined to use `===' nowadays.
>>>> Pardon ? I don't understand that you dare to use '===', and advocate
>>>> to feature-detect on 'document' at the same time. The chance that
>>>> '===' fails, is much, much higher.
>>> In terms of scripts that run in browsers, I agree.
>> I wonder, is there some *evidence* to support your opinion?
>
> Yes.
Where?
>> After discussion about `===' vs `==' here some time ago, I have included
>> `===' in the ECMAScript Support Matrix. It is documented to work since
>> JavaScript 1.3, JScript 1.0 (tests pending). It is tested to work since
>> JavaScript 1.3 (in NN 4.78). It works in Opera 5.02 and 9.52 (and probably
>> versions in-between too, tests pending), and Konqueror 3.5.9 (and probably
>> earlier, KJS source analysis and maybe tests pending).
>>
>> So where does it fail?
>
> In very old browsers,
Such as?
> but that's beside the (main) point.
Which would be?
>>>>>> If you want to check whether 2 numerical values are equal, then
>>>>>> use '==' !
>>>>> No and no.
>>>> As I repeated above, the code in question holds two operands of the
>>>> same type; so there is absolutely nothing wrong to use '=='.
>>> Exactly.
>> Yes, there is. Read the Spec.
>
> Don't need to. There's nothing wrong with using == in this case.
Indeed; I stand corrected:
| 11.9.1 The Equals Operator ( == )
|
| The production
| EqualityExpression : EqualityExpression == RelationalExpression
| is evaluated as follows:
|
| 1. Evaluate EqualityExpression.
| 2. Call GetValue(Result(1)).
| 3. Evaluate RelationalExpression.
| 4. Call GetValue(Result(3)).
| 5. Perform the comparison Result(4) == Result(2). (Section 11.9.3.)
| 6. Return Result(5).
|
| [...]
| 11.9.3 The Abstract Equality Comparison Algorithm
|
| The comparison x == y, where x and y are values, produces true or false.
| Such a comparison is performed as follows:
|
| 1. If Type(x) is different from Type(y), go to step 14.
| 2. If Type(x) is Undefined, return true.
| 3. If Type(x) is Null, return true.
| 4. If Type(x) is not Number, go to step 11.
| 5. If x is NaN, return false.
| 6. If y is NaN, return false.
| 7. If x is the same number value as y, return true.
| [...]
as compared to
| 11.9.4 The Strict Equals Operator ( === )
|
| The production
| EqualityExpression : EqualityExpression === RelationalExpression
| is evaluated as follows:
|
| 1. Evaluate EqualityExpression.
| 2. Call GetValue(Result(1)).
| 3. Evaluate RelationalExpression.
| 4. Call GetValue(Result(3)).
| 5. Perform the comparison Result(4) === Result(2). (See below.)
| 6. Return Result(5).
|
| [...]
| 11.9.6 The Strict Equality Comparison Algorithm
|
| The comparison x === y, where x and y are values, produces true or false.
| Such a comparison is performed as follows:
|
| 1. If Type(x) is different from Type(y), return false.
| 2. If Type(x) is Undefined, return true.
| 3. If Type(x) is Null, return true.
| 4. If Type(x) is not Number, go to step 11.
| 5. If x is NaN, return false.
| 6. If y is NaN, return false.
| 7. If x is the same number value as y, return true.
| [...]
>>> Using === for such cases obfuscates the code.
>> Rubbish.
>
> Nope. First thing I would think on seeing === is that the two
> operands could be different types. Using == makes the author's
> intentions clear.
Then we have to agree to disagree here.
>>>>>> Your advice to feature-detect on 'document' is simply hilarious.
>>>>> You are easily amused, but your ignorance does not mean anything
>>>>> against the correctness of this approach.
>>>> Which "ignorance" would that be ? The "ignorance" to not see that a
>>>> feature-test on 'document' is necessary ?
>>> You are right as far as browser scripts go.
>> Wishful thinking.
>
> I wonder what usable browser would lack a document object. No
> evidence to support that AFAIK.
Well, evidence has been provided to suggest that it is at least possible.
Who would have thought before that there were a script-enabled browser that
supports `alert' but not `document.write'?
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
Thomas 'PointedEars' Lahn
You, too, appear to have problems recognizing the difference between
language features and host features.
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>
David Mark
wrote:
Looks like bait to me. Keep it.
JR
wrote:
> >>>>>> Your advice to feature-detect on 'document' is simply hilarious.
> >>>>> You are easily amused, but your ignorance does not mean anything
> >>>>> against the correctness of this approach.
> >>>> Which "ignorance" would that be ? The "ignorance" to not see that a
> >>>> feature-test on 'document' is necessary ?
> >>> You are right as far as browser scripts go.
> >> Wishful thinking.
>
> > I wonder what usable browser would lack a document object. No
> > evidence to support that AFAIK.
>
> Well, evidence has been provided to suggest that it is at least possible.
> Who would have thought before that there were a script-enabled browser that
> supports `alert' but not `document.write'?
Again, TPE is trying to prove the existence of little green men... TPE
went bonkers.
--
JR
David Mark
wrote:
How so and how would such a browser be usable (in terms of DOM
scripting?)
> Who would have thought before that there were a script-enabled browser that
> supports `alert' but not `document.write'?
I certainly did. There's a big difference between no document and no
write method. I don't see how the alert method (or lack thereof) is
relevant here.
Should also be mentioned that the one browser found lacking this
method was also lacking gEBI, so is also less than usable for most DOM
scripting.