Preloading images?

[Fabian]

var preload1 = new Image(); preload1.src = "/pic/yay.gif";
var preload2 = new Image(); preload2.src = "/pic/nay.gif";

The above is meant to preload image files, yes? Problem is, it doesnt
seem to be doing so in practice. Any idea where Im going wrong? Could it
be that things work differnetly when in an attached .js file?

 

[Thomas 'PointedEars' Lahn]

var preload1 = new Image(); preload1.src = "/pic/yay.gif";
var preload2 = new Image(); preload2.src = "/pic/nay.gif";

The above is meant to preload image files, yes?

Yes, and depending on the (file) size of the image,
it is a Bad Thing as explained a few days ago.

Problem is, it doesnt seem to be doing so in practice.

How do you get that idea? Do you get any script errors?

Any idea where Im going wrong?

It is simply that at least on the Internet you cannot modify the user's
cache settings and what you observe here is possibly what happens if they
do not match what you assume.

Could it be that things work differnetly when in an attached .js file?

Depends on what you mean by `attached'.


PointedEars

 

[Fabian]

Yes, and depending on the (file) size of the image,
it is a Bad Thing as explained a few days ago.

The images in question at < 3kb each, and the page wont make sense if
they dont get displayed.

How do you get that idea? Do you get any script errors?

No errors I can tell anyway. Its at
www.lajzar.co.uk/en/index.html/animals.html (amongst others) if you want
to look. Since I have no idea where in the code a bug of this kind might
reside, it seems pointless posting any in the group at this stage. The
prime suspect was apparently the wrong one.

It is simply that at least on the Internet you cannot modify the user's
cache settings and what you observe here is possibly what happens if they
do not match what you assume.

Id have hoped I would at least be able to modify this particular user's
cache settings to enable preloading.

file?

Depends on what you mean by `attached'.

<script src="blah.js" language="GuavaJuice">
</script>

That kind of attached. There is another way?

 

[Stephen]

Hi there, and apologies if this is a rather long-winded answer...

Fabian wrote:

var preload1 = new Image(); preload1.src = "/pic/yay.gif";
var preload2 = new Image(); preload2.src = "/pic/nay.gif";

The above is meant to preload image files, yes?

Yes, [...SNIP...]

The images in question at < 3kb each, and the page wont make sense if
they dont get displayed.

Problem is, it doesnt seem to be doing so in practice.

How do you get that idea? [...SNIP...]

No errors I can tell anyway.

Because there's no code there to detect the error that's happening ...

Its at

www.lajzar.co.uk/en/index.html/animals.html

Actually I found at
www.lajzar.co.uk/en/animals.html

(amongst others) if you want

to look. Since I have no idea where in the code a bug of this kind might
reside, it seems pointless posting any in the group at this stage. The
prime suspect was apparently the wrong one.

It's not a javascript problem...

Id have hoped I would at least be able to modify this particular user's
cache settings to enable preloading.

I do not believe the user's browser cache settings have anything to do
with whether the images "preload"

No. Don't believe so ...

But here's what happened when I tried loading the "animals.html" page:

1. Browser requests animals.html
2. Server says 200 ok, here it is
3. Browser sees it needs css.css & requests it
4. Server says 200 ok, here it is
5. Browser requests "favicon.ico"
6. Server says 200 ok, here it is
[ don't get bored yet ...]
7. Browser sees it needs "game1.js" and requests it.
8. Server says 200 ok, here it is:
Note, your Apache server serves this as application/x-javascript.
This is probably as ok as anything, but it may be more usual to serve it
as text/javascript. Though this has nothing to do with the problem.

[This is the interesting part:]
9. Browser sees it needs yay.gif and requests it
10. Server says 404, can't find it (!!)
11. Browser sees it needs nay.gif and requests it
12. Server says 404, can't find it (!!)

Has nothing to do with cache; has to do with the server can't find the
images to serve. They are being requested as /pic/yay.gif (or
/pic/nay.gif) from www.lajzar.co.uk

When you call the checkAnswers() function, you construct the yay/nay
image sources as

"pic/yay.gif"
"pic/nay.gif"

That is, without the starting "/". In this case the images show. So the
answer is that in your preload code you're trying to fetch the images
from the wrong place.

I think you can put an onerror event handler on the image preloads to
detect the error:

preload1 = new Image();
preload1.onerror=function(){alert("No Preload-yay");};
preload1.src = "/pic/yay.gif";

ALthough that's not very pretty. And as you've coded the checkAnswers()
function (with the correct image location) the problem fixes itself
(even if image showing might not be as fast as you'd like).

HTH,
Stephen

 

[Fabian]

Problem is, it doesnt seem to be doing so in practice.

How do you get that idea? [...SNIP...]

No errors I can tell anyway.

Because there's no code there to detect the error that's happening ...

I do my error checking mostly with the Mk I eyeball debugging system.
For added error checking potential, I have two running at the same time.
It is primitive, but it mostly works.

Its at

Actually I found at
www.lajzar.co.uk/en/animals.html

As I said, it only *mostly* works

But here's what happened when I tried loading the "animals.html" page:
....

[This is the interesting part:]
9. Browser sees it needs yay.gif and requests it
10. Server says 404, can't find it (!!)
11. Browser sees it needs nay.gif and requests it
12. Server says 404, can't find it (!!)

Has nothing to do with cache; has to do with the server can't find the
images to serve. They are being requested as /pic/yay.gif (or
/pic/nay.gif) from www.lajzar.co.uk

When you call the checkAnswers() function, you construct the yay/nay
image sources as

"pic/yay.gif"
"pic/nay.gif"

ok, I am stupid. Thanks for finding the problem. A virtual rate of beer
is on its way to you now

 

[Jim Ley]

Yes,

No, it will depend on the HTTP headers sent with those gifs and user
settings.

and depending on the (file) size of the image,
it is a Bad Thing as explained a few days ago.

I think you should inform both the various W3 working groups who ares
putting the behaviour into the actual mark-up languages, they seem
happy that it is a good idea.

Jim.

 

[Stephen]

Problem is, it doesnt seem to be doing so in practice.

How do you get that idea? [...SNIP...]


No errors I can tell anyway.

Because there's no code there to detect the error that's happening ...

I do my error checking mostly with the Mk I eyeball debugging system.
For added error checking potential, I have two running at the same time.
It is primitive, but it mostly works.

Its at


Actually I found at
www.lajzar.co.uk/en/animals.html

As I said, it only *mostly* works

But here's what happened when I tried loading the "animals.html" page:

...


[This is the interesting part:]
9. Browser sees it needs yay.gif and requests it
10. Server says 404, can't find it (!!)
11. Browser sees it needs nay.gif and requests it
12. Server says 404, can't find it (!!)

Has nothing to do with cache; has to do with the server can't find the
images to serve. They are being requested as /pic/yay.gif (or
/pic/nay.gif) from www.lajzar.co.uk

When you call the checkAnswers() function, you construct the yay/nay
image sources as

"pic/yay.gif"
"pic/nay.gif"

ok, I am stupid. Thanks for finding the problem. A virtual rate of beer
is on its way to you now

Didn't by any means intend to imply you're stupid... I make that same
mistake far more than I'll admit in public . You know, at least, that
your initial observation was exactly right: the preload *wasn't* taking
place ... And thanks for the beer!

S.

 

[Thomas 'PointedEars' Lahn]

It's not a javascript problem...

That's definitely true.

I do not believe the user's browser cache settings have anything to do
with whether the images "preload"

But they actually have. What achieved by preloading is only that there is an
Image object created and a resource is accessed by a HTTP request (if not on
the local file system.) That resource is saved in the cache and therefore
need not to be downloaded a second time if, and only if, it is then still in
the cache, which speeds up the display. Although JavaScript is a common way
to do this, you could also do the "preloading" by putting the image on a
previous page and, if supported, even by prefetching the resource with HTML
(`link' element) or CSS (`background-image' property).


PointedEars

 

[Thomas 'PointedEars' Lahn]

No, it will depend on the HTTP headers sent with those gifs and user
settings.

I also wrote that implicitely. The above is in fact *meant*
to preload images. The result does not negate the intent.

I think you should inform both the various W3 working groups who ares
putting the behaviour into the actual mark-up languages, they seem
happy that it is a good idea.

By putting the functionality into recommendations, it is by no means said
that you should use that feature when not appropriate. It merely provides
the possibility to use the feature. Unless there are no more analog modems,
it seems at least questionable to use that particular feature on the Web,
especially when done without regard to the amount of data to be transmitted.


PointedEars, connected by a 56k modem

 

[Thomas 'PointedEars' Lahn]

"Thomas 'PointedEars' Lahn" [...] wrote [...]

Yes, and depending on the (file) size of the image,
it is a Bad Thing as explained a few days ago.

The images in question at < 3kb each,

That is acceptable to me as user of a 56k analog modem.

and the page wont make sense if they dont get displayed.

See the problem? What if the user has disabled images? What if they use a
user agent that cannot display images, let's say a text browser or a Braille
line? The `alt' attribute is your friend. If that does not suffice, you have
greater problems with your concept than that your images do not preload.

Id have hoped I would at least be able to modify this particular user's
cache settings to enable preloading.

No, forget about it. My cache is *my* cache.
How dare you change what I find appropriate?

<script src="blah.js" language="GuavaJuice">
</script>

That kind of attached. There is another way?

`Attached' could have meant that the .js file is an attachment of an
evil[tm] HTML e-mail and other causes of the problem would have had
to be considered.


PointedEars

 

[Jim Ley]

I also wrote that implicitely. The above is in fact *meant*
to preload images. The result does not negate the intent.

No, it's a side effect really....

By putting the functionality into recommendations, it is by no means said
that you should use that feature when not appropriate. It merely provides
the possibility to use the feature. Unless there are no more analog modems,
it seems at least questionable to use that particular feature on the Web,
especially when done without regard to the amount of data to be transmitted.

How strange, because of certain pecularities in your environment you
choose to impose a behaviour on everyone - it would be trivial of you
to block the preloading, and that would make much more sense all
around.

Jim.

 

[Fabian]

See the problem? What if the user has disabled images? What if they use a
user agent that cannot display images, let's say a text browser or a Braille
line? The `alt' attribute is your friend. If that does not suffice, you have
greater problems with your concept than that your images do not

preload.

Trust me, this is a complete and utter non-issue. This section is being
written with Japanse schoolchildren in mind, particularly the school
computer networks. The school computers in every school I have visited
use Explorer 6 with all normal display options on. As for their home
computers, lets just say that Japanese kids arent noted for thinking
creatively. I can be fairly certain what their home set up is because it
simply wouldnt occur to them that they can change the settings without
permission from tech support. That goes double for their parents.

If they are using a text browser with braille support, learning English
would be the least of their problems for this hypothetical Japanese kid.

If anything, the main useability problem is too much text and not enough
pictures.

No, forget about it. My cache is *my* cache.
How dare you change what I find appropriate?

Perhaps I was writing too subtlely. "This particular user" is a subtle
way of referring to myself.

 

[Thomas 'PointedEars' Lahn]

How strange, because of certain pecularities in your environment you
choose to impose a behaviour on everyone - it would be trivial of you
to block the preloading, and that would make much more sense all
around.

Your sarcasm aside, I do not impose behaviours on everyone because of my
needs. That I am currently using an analog modem (I had the opportunity to
connect via a 10 MBit LAN until a month ago) emphasizes only that I do know
of what I am writing about when asking to reconsider to use certain
features. There are of course more than one user with an analog modem. What
a Web author wants are visitors. Thus it is not wise to disregard the needs
of *any* visitor if this can be prevented. If you read standards and (W3C)
recommendations thourough, you find this attitude expressed in the features
they describe.


PointedEars

 

[Jim Ley]

Your sarcasm aside, I do not impose behaviours on everyone because of my
needs.

So why suggest that other people stop using preloading, an important
usability aid for a great number of people, because you're blessed
with 28K or so connection I've often used 9.6K and shared 28k
connection between 10 people or more. I just modified by
browser/behaviour so as it didn't harm me, you're free to do the same.

What
a Web author wants are visitors. Thus it is not wise to disregard the needs

Preloading is a lot more relevant to low bandwidth users, as it
ensures that the usability increase still works, by ensuring the
materials are available. In high bandwidth situations, it's hardly
relevant as the content comes down, but as I say - it's easy enough to
disable.

Yes authors want visitors, and yes their site needs to be usable -
preloading can provide that - obviously forcing large images etc. down
peoples throats is bad, but that is wholly irrelevant to preloading.

Jim.

 

[Thomas 'PointedEars' Lahn]

So why suggest that other people stop using preloading,

I have only suggested that they think about it before using it.

I just modified by browser/behaviour so as it didn't harm me, you're free
to do the same.

That may be OK to you, but who of us is now imposing behaviors on others
here when you write that it is therefore also OK to others? Do you really
think that someone except of you will *ever* adjust their settings to fit
for only *one* particular website? There are plenty of other websites out
there! Besides, sometimes it is only possible for the administrator to
change such settings, have you considered that?

Preloading is a lot more relevant to low bandwidth users, as it
ensures that the usability increase still works, by ensuring the
materials are available.

Since users pay for downloaded data as well as connection time I doubt
they would appreciate it if their download or connection time quota is
spoiled by downloading (a bunch of navigational) images they do not want
because they do not need them (and vice-versa.) Multimedia experience is
not everything, sometimes you are just looking for useful information.


PointedEars

 

[Jim Ley]

I have only suggested that they think about it before using it.

That is not what you said in this thread.

That may be OK to you, but who of us is now imposing behaviors on others
here when you write that it is therefore also OK to others?

Neither of us... All web authoring is suggesting, suggesting
something be preloaded can be important for usability, telling people
not to do is it is not helpful.

Since users pay for downloaded data as well as connection time I doubt
they would appreciate it if their download or connection time quota is
spoiled by downloading (a bunch of navigational) images they do not want
because they do not need them (and vice-versa.)

Where did I say anything about using images for navigation - that's
most certainly a really bad idea, and I can fully agree with you that
it is bad - but what's that got to do with preloading images, other
than the fact some people misuse it in that way?

Jim.

 

[Stephen]

Stephen wrote:

[...snip...]

I do not believe the user's browser cache settings have anything to do
with whether the images "preload"

But they actually have.

Actually, I stand by the statement I made, where "preload" is doing what
the OP originally wrote about:

var preload1 = new Image(); preload1.src = "/pic/yay.gif";
var preload2 = new Image(); preload2.src = "/pic/nay.gif";

This is based on my observations and is not simply an assertion.

What achieved by preloading is only that there is an
Image object created and a resource is accessed by a HTTP request (if not on
the local file system.)

Pretty much ok, but for that "file system" part. The term "cache" is
really a bit ambiguous: there is disk cache and memory cache. So the
browser uses memory for storing some of its "stuff" -- and it is into
memory that the "preloaded" images go; they may also get stored in disk
cache. Even if I turn off disk caching the memory part still works. By
my observation, this even works in Opera, where one can explicitly "turn
off" memory caching.

That resource is saved in the cache and therefore
need not to be downloaded a second time if, and only if, it is then still in
the cache, which speeds up the display.

It is being in memory that makes rollovers work really fast. Even
fetching a (disk)-cached copy could be too long. The point is to make
rollovers appear instantaneous.

Again, I do not believe there is any user browser cache setting that has
anything to do with whether the images "preload".

Of course, a clear, unambiguous example illustrating a user setting for
browser cache that causes "preloads" to fail could change my mind on the
matter.

Regards,
Stephen

 

[Fabian]

Since users pay for downloaded data as well as connection time I doubt
they would appreciate it if their download or connection time quota is
spoiled by downloading (a bunch of navigational) images they do not want
because they do not need them (and vice-versa.) Multimedia experience is
not everything, sometimes you are just looking for useful information.

For Japanese schholchildren, my target audience, multimedia is king. A
plain text site would have them fall asleep in seconds.

 

[Thomas 'PointedEars' Lahn]

For Japanese schholchildren, my target audience, multimedia is king. A
plain text site would have them fall asleep in seconds.

Read again. I did not write that you must discard images.


HTH

PointedEars

P.S.:
Your comb-like quoting (correct translation?) sucks. Alas I do not know
a non-German tutorial/FAQ for Outlook Express (Google should provide one)
but I suggest you use MorVer or OE-Tools to avoid that in the future as
many people have before.

 

[Fabian]

P.S.:
Your comb-like quoting (correct translation?) sucks. Alas I do not know
a non-German tutorial/FAQ for Outlook Express (Google should provide one)
but I suggest you use MorVer or OE-Tools to avoid that in the future as
many people have before.

As I have no idea what comb-like quoting is, and as you are the first
person ever to comment unfavourably on my quoting style, I think I shall
pass on changing my modus operandi.