Need Help Creating an Image Slideshow

[David Mark]

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

 

[JR]

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

 

[Thomas 'PointedEars' Lahn]

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.

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.

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.

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.

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]

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.

 

[David Mark]

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.

Beats me.

That about sums it up.

 

[Bart Van der Donck]

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.

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

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 ?

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.

 

[David Mark]

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.

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.

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.

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]

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?

Exactly.

Yes, there is. Read the Spec.

Using === for such cases obfuscates the code.
Rubbish.


You are right as far as browser scripts go.

Wishful thinking.

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

 

[David Mark]

I wonder, is there some *evidence* to support your opinion?
Yes.


After discussion about `===' vs `==' here some time ago, I haveincluded
`===' in the ECMAScript Support Matrix.  It is documented to worksince
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.

Yes, there is.  Read the Spec.

Don't need to. There's nothing wrong with using == in this case.

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.

Wishful thinking.

I wonder what usable browser would lack a document object. No
evidence to support that AFAIK.

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.


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]

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

 

[Thomas 'PointedEars' Lahn]

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.


PointedEars

 

[David Mark]

Just tested: Works fine in JScript 5.1.5010 (IE/MSHTML 5.01, released in
1999).  Do I need to go further back?

I move for a mistrial.

 

[Thomas 'PointedEars' Lahn]

Where?


In very old browsers,

Such as?

but that's beside the (main) point.

Which would be?

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

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.

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

 

[Thomas 'PointedEars' Lahn]

I move for a mistrial.

You, too, appear to have problems recognizing the difference between
language features and host features.


PointedEars

 

[David Mark]

You, too, appear to have problems recognizing the difference between
language features and host features.

Looks like bait to me. Keep it.

 

[JR]

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.

 

[David Mark]

Where?

In very old browsers,

Such as?

but that's beside the (main) point.

Which would be?

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

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.

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.

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.