Need Help Creating an Image Slideshow

M

Madcap

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

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

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
 
M

Madcap

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.

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
 
B

Bart Van der Donck

Madcap said:
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,
 
M

Madcap

Awesome, I just added an array for the interval and changed the tags
to my own images and it's working fine.

Thanks!
 
T

Thomas 'PointedEars' Lahn

Bart said:
<!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.

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 = imageFactory(f);
}
}
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
}
};

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
 
T

Thomas 'PointedEars' Lahn

Thomas said:
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
 
B

Bart Van der Donck

Thomas said:
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

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 = imageFactory(f);
    }
  }
 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
 
T

Thomas 'PointedEars' Lahn

Bart said:
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.

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.

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 = imageFactory(f);
}


Here the array of string values becomes an array of Image object references
if supported.
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 said:
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.
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
 
B

Bart Van der Donck

Thomas said:
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.
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.
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.
No, I corrected myself one time in two places of the same code.

Which are two corrections.
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.
 
T

Thomas 'PointedEars' Lahn

Bart said:
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.
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.
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.

[ 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.
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.
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.
Aha. You have a magic hat to make code disappear.

No, the code would not disappear completely. However, it disappears from
the user code.
Which are two corrections.

Quibbling over words. I corrected myself only once.
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
 
B

Bart Van der Donck

Thomas said:
...
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();' ?
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.
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.
See above.

Netscape Navigator 2.01. ?
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.
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.
 
T

Thomas 'PointedEars' Lahn

Bart said:
Thomas said:
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.
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.
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.

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.
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.
Netscape Navigator 2.01. ?

Probably yes. Hardly relevant nowadays, though.
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
 
E

Erwin Moller

Thomas 'PointedEars' Lahn schreef:
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
 
T

Thomas 'PointedEars' Lahn

Thomas said:
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. [...]

Err, _decade_. But it was in the last century :)


PointedEars
 
B

Bart Van der Donck

Thomas said:
That remains to be seen.  I am working on it.

I am curious.
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
'==' !
Probably yes.  Hardly relevant nowadays, though.

Understatement. There is no need to be compatible with Netscape
Navigator 2.01. nowadays (javascript 1.0.).
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.
 
D

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

Thomas 'PointedEars' Lahn

Conrad said:
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?


TIA

PointedEars
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,756
Messages
2,569,540
Members
45,025
Latest member
KetoRushACVFitness

Latest Threads

Top