Question, need expert help pre-loading images properly (IE + FireFox), thank you :)

[SaraLeePerson]

Dear group,

I am seeking a easy to maintain and more importantly *working* way to
pre-fetch images, so the pages I develop load smoothly without seeing
the images kick in flicker as they usually do. Important - I need
this to work on Internet Explorer 6.0+ and FireFox.

I am presently using at the head of the page,

pic100= new Image;
pic100.src="./imageme.gif";

However, it doesn't seem to work on FireFox at all. I've tried
different combinations with the URL path, but I don't know what I am
doing wrong. Can someone please assist me with this boggle?

Thank you very much in advance for any assistance.

Best wishes, Sara.

 

[Stevo]

pic100= new Image;
pic100.src="./imageme.gif";
However, it doesn't seem to work on FireFox at all. I've tried
Thank you very much in advance for any assistance.

I could be wrong and using new Image; is just fine, but I've always used
new Image();

You didn't mention how you use pic100 so that's all there is to go on.

 

[SaraLeePerson]

I could be wrong and using new Image; is just fine, but I've always used
new Image();

You didn't mention how you use pic100 so that's all there is to go on.

Hi

Presently, the configuration for FireFox and IE I have is

<script>
pic100= new Image;
pic100.src="./imageme.gif";
</script>

<img src=./imageme.gif>

 

[Thomas 'PointedEars' Lahn]

I am seeking a easy to maintain and more importantly *working* way to
pre-fetch images, so the pages I develop load smoothly without seeing
the images kick in flicker as they usually do.

Please don't.

Thank you very much in advance for any assistance.

You're welcome.


F'up2 cljs

PointedEars

 

[Stevo]

<script>
pic100= new Image;
pic100.src="./imageme.gif";
</script>

<img src=./imageme.gif>

OK, you're expectations are too high. That pic100.src *is* starting to
preload the file, but your img tag is going to start using it long
before it will be finished loading. What people usually do in cases like
this is to set the img src to a blank image, and only when pic100.src
has finished loading, do you then change the src of the img to point to
it. If you google "preload images javascript" you'll find lots of
ready-coded examples.

 

[Peter Michaux]

Dear group,

I am seeking a easy to maintain and more importantly *working* way to
pre-fetch images, so the pages I develop load smoothly without seeing
the images kick in flicker as they usually do. Important - I need
this to work on Internet Explorer 6.0+ and FireFox.

I am presently using at the head of the page,

pic100= new Image;
pic100.src="./imageme.gif";

I'm rewriting some old preload code to try to reduce server
connections. For some reason, after the window.onload event, each use
of the following code

var img = new Image();
img.src = someUrl;

causes a new connection to the server (Apache). Because many (~100)
images now need to be preloaded, this is causing Apache grief. (I
didn't write the specs on this page. It is legacy and needs a quick
fix until I have time for a real solution.)

If the same many images are just written into the page with <img
src="someUrl"> the same initial connection is being used to get all
images. I believe this is Apache's pipelining feature at work to
conserve connections.

Does anyone know about this situation and is their a standard
solution?

I have a few ideas to try when the server admin is available but I
thought I'd ask since the topic has appeared.

Thanks,
Peter

 

[SAM]

Peter Michaux a écrit :

I'm rewriting some old preload code to try to reduce server
connections. For some reason, after the window.onload event, each use
of the following code

var img = new Image();
img.src = someUrl;

causes a new connection to the server (Apache). Because many (~100)
images now need to be preloaded, this is causing Apache grief.

And post-writing css rules (or post-writing a call to a *.css) for this
100 images as backrground of the same transparent image opened in the page ?
(probably they won't appear in order)

 

[Bone Ur]

I'm rewriting some old preload code to try to reduce server
connections. For some reason, after the window.onload event, each use
of the following code

var img = new Image();
img.src = someUrl;

causes a new connection to the server (Apache). Because many (~100)
images now need to be preloaded, this is causing Apache grief. (I
didn't write the specs on this page. It is legacy and needs a quick
fix until I have time for a real solution.)

If the same many images are just written into the page with <img
src="someUrl"> the same initial connection is being used to get all
images. I believe this is Apache's pipelining feature at work to
conserve connections.

Does anyone know about this situation and is their a standard
solution?

I have a few ideas to try when the server admin is available but I
thought I'd ask since the topic has appeared.

You can j/s preload sequentially: ie, not starting the following preload
until the previous is finished. I've done that and it works. But a
better idea (I think) is just to make a position:absolute;
visibility:hidden; div "layer" encompassing all the images which won't
show because of the css.

 

[David Mark]

You can j/s preload sequentially: ie, not starting the following preload
until the previous is finished. I've done that and it works. But a
better idea (I think) is just to make a position:absolute;
visibility:hidden; div "layer" encompassing all the images which won't
show because of the css.

That will mess up the semantics of the page and will look strange when
style is disabled. For the scriptless approach, it is better to use
background images.

 

[Bone Ur]

Well bust mah britches and call me cheeky, on Sun, 28 Oct 2007 08:57:45 GMT
David Mark scribed:

That will mess up the semantics of the page and will look strange when
style is disabled. For the scriptless approach, it is better to use
background images.

Background images don't always load as one might wish, though. The
styling-disabled is a valid concern, but despite conventional mythology,
styling is necessary nowadays and anyone who disables it except for testing
is a moron. As for semantics - phffft! Very few pages have correct
semantics, anyway, and a sequential list of links in a "layer" will
certainly not mess them up if they are correct.

 

[David Mark]

Well bust mah britches and call me cheeky, on Sun, 28 Oct 2007 08:57:45 GMT
David Mark scribed:



Background images don't always load as one might wish, though. The

I don't know what you mean by that. But the typical need for
preloading is for rollovers and the like, so it isn't a catastrophe if
the images fail to preload.

styling-disabled is a valid concern, but despite conventional mythology,
styling is necessary nowadays and anyone who disables it except for testing

That is only part of it. Some agents don't support style at all.

is a moron. As for semantics - phffft! Very few pages have correct

It is not the users' fault if a document is poorly designed.

semantics, anyway, and a sequential list of links in a "layer" will

Very few pages are written by competent Web developers.

certainly not mess them up if they are correct.

What list of links? The suggestion was for a "layer" with hidden
images. Search engines, screen readers, style-challenged agents, etc.
will have no idea what to make of such a thing.

 

[Neredbojias]

Well bust mah britches and call me cheeky, on Mon, 29 Oct 2007 11:34:51
GMT David Mark scribed:

I don't know what you mean by that. But the typical need for
preloading is for rollovers and the like, so it isn't a catastrophe if
the images fail to preload.

No, of course not. But I seem to remembering seeing in the past
background images sometimes loading last (-in ie, I think) and that sort
of goes counter to the whole idea. And neither is it a catastrophe if
one adds a hidden layer with regular images.

That is only part of it. Some agents don't support style at all.

No, but I'll bet 99%+ used actively on the Web today do. A real
consideration might be the useragents of ipods, picture phones and the
like.

It is not the users' fault if a document is poorly designed.

Who said it was? We are discussing the viability of an additional layer
for a specific purpose.

Very few pages are written by competent Web developers.


What list of links? The suggestion was for a "layer" with hidden
images. Search engines, screen readers, style-challenged agents, etc.
will have no idea what to make of such a thing.

I meant "list of images". Why would search engines have a problem? As
for screen readers, it may cause some confusion but I don't evaluate this
anywhere near reason enough to avoid the technique. Unquestionably, it
will work and work well. Background images may also work, but there is
some doubt. And lastly, I'm not one of those who subscribe to the "least
common denominator approach" to web page creation just to strictly
satisfy certain concepts which are arguable to begin with.

 

[David Mark]

Well bust mah britches and call me cheeky, on Mon, 29 Oct 2007 11:34:51
GMT David Mark scribed:



No, of course not. But I seem to remembering seeing in the past
background images sometimes loading last (-in ie, I think) and that sort
of goes counter to the whole idea. And neither is it a catastrophe if
one adds a hidden layer with regular images.



No, but I'll bet 99%+ used actively on the Web today do. A real

For the sake of argument, say it is 0.1%. Multiply that by the number
of users on the Web today and you get a fairly substantial number.

consideration might be the useragents of ipods, picture phones and the
like.



Who said it was? We are discussing the viability of an additional layer
for a specific purpose.

You said that those who disabled style were morons. If the document
doesn't work in that case, does it reflect poorly on the user or the
author?

I meant "list of images". Why would search engines have a problem? As

Do you mean a series of images. An HTML list would further complicate
the semantics.

for screen readers, it may cause some confusion but I don't evaluate this
anywhere near reason enough to avoid the technique. Unquestionably, it

Why would you want to confuse the sight-impaired for the sake of
faster rollovers?

will work and work well. Background images may also work, but there is

It will work for users with CSS support and without impaired vision.

some doubt. And lastly, I'm not one of those who subscribe to the "least
common denominator approach" to web page creation just to strictly

I don't see what this has to do with an LCD approach.

satisfy certain concepts which are arguable to begin with.

It is arguable whether the images will load faster as inline or
background images. So why use a technique that may or may not
slightly improve the load time of rollovers, when it will definitely
have other negative implications?

 

[dorayme]

And lastly, I'm not one of those who subscribe to the "least
common denominator approach" to web page creation just to strictly
satisfy certain concepts which are arguable to begin with.

Presumably "just to satisfy certain concepts" indicates you think
it a dumb trivial clerical obsessive motive. Otherwise why use
these words?

The web author who tries hard to make his pages as assessable as
possible, including the crucial 'degrading well' property, is not
necessarily exhibiting a psychological fault. He could be
motivated by a desire to make his pages as assessable as
possible. There is a crucial difference. One is a rational thing,
the other a irrational one.

 

[Bergamot]

The
styling-disabled is a valid concern, but despite conventional mythology,
mythology?

styling is necessary nowadays and anyone who disables it except for testing
is a moron.

You might be surprised how many sites I have to disable CSS on just so I
can read them, including many big-name sites. I'd be a moron if let
stupid deeziners tell me how I must set up my PC or how I must view a
web page.

As for semantics - phffft! Very few pages have correct semantics,

That's irrelevant. 2 wrongs don't make a right and all that.

 

[Neredbojias]

Well bust mah britches and call me cheeky, on Mon, 29 Oct 2007 12:33:33
GMT David Mark scribed:

For the sake of argument, say it is 0.1%. Multiply that by the number
of users on the Web today and you get a fairly substantial number.

How many atoms are in a thimble? And what is that thimble to the planet?

You said that those who disabled style were morons. If the document
doesn't work in that case, does it reflect poorly on the user or the
author?

Could be either or both. But if the document works well with authored
styles and not well without them, who's the moron?

Do you mean a series of images. An HTML list would further complicate
the semantics.

Yes, a series of images. -Used "list" in the common generic form.
("Form", too.)

Why would you want to confuse the sight-impaired for the sake of
faster rollovers?

I invariably optimize my pages for the visual audience. So do most
people. Html is primarily a visual medium despite the bs.

It will work for users with CSS support and without impaired vision.


I don't see what this has to do with an LCD approach.

-Blindly following the standards because they are standards and
"recommended". Sometimes you have to think for yourself.

It is arguable whether the images will load faster as inline or
background images. So why use a technique that may or may not
slightly improve the load time of rollovers, when it will definitely
have other negative implications?

Because the other negative implications are not as negative as doing
without the method under discussion - at least in some instances.
Furthermore, the other negative implications can be eliminated or reduced
with authoring care.

This is an old argument, hashed and rehashed to death. You have every
right to believe what you want, but I maintain the same right for myself.
A lot of the so-called wisdom relating to markup is just pedantic crap or
something over-exaggerated to make a point. In short, if it works for
99%+ of the browsing population, it works. Period.

 

[Neredbojias]

Well bust mah britches and call me cheeky, on Mon, 29 Oct 2007 19:32:36 GMT
dorayme scribed:

Presumably "just to satisfy certain concepts" indicates you think
it a dumb trivial clerical obsessive motive. Otherwise why use
these words?

The web author who tries hard to make his pages as assessable as
possible, including the crucial 'degrading well' property, is not
necessarily exhibiting a psychological fault. He could be
motivated by a desire to make his pages as assessable as
possible. There is a crucial difference. One is a rational thing,
the other a irrational one.

An author _should_ try to make his pages as accessible as possible, but
sacrificing popular and versatile utility for coverage of uncommon
conditions and situations is just plain dumb. Do you still consider
Netscape 4.xx in your work? I'm sure there's still a few diehards out
there...

The real idea is you do what you can. If I have to concede a little
semantics to a page-enhancing preload, it would be totally idiotic not to
do so.

 

[Neredbojias]

Well bust mah britches and call me cheeky, on Mon, 29 Oct 2007 20:00:51
GMT Bergamot scribed:

mythology?


You might be surprised how many sites I have to disable CSS on just so
I can read them, including many big-name sites. I'd be a moron if let
stupid deeziners tell me how I must set up my PC or how I must view a
web page.

Not relevant. I'm talking about a site where you _don't_ have to disable
styling and will suffer a negative impact if you do. This, btw, is most
sites.

That's irrelevant. 2 wrongs don't make a right and all that.

- The lesser evil and all that. If the nerds would just wake up and use
some real-world logic instead of their house-of-class deductive pseudo-
logic, the problems with markup, etc., wouldn't be half so bad to begin
with.

 

[Bergamot]

Well bust mah britches and call me cheeky, on Mon, 29 Oct 2007 20:00:51
GMT Bergamot scribed:


Not relevant.

?
I wasn't responding to one of your posts, but to one by Bone Ur.

 

[dorayme]

dorayme:


An author _should_ try to make his pages as accessible as possible, but
sacrificing popular and versatile utility for coverage of uncommon
conditions and situations is just plain dumb.

A good author does not have to "sacrifice" fancy things to
"cover" the less common type of users, (especially the disabled,
the ones on very slow dialup etc etc). It may be hard work for
sure, but it is not a case of sacrificing, at least not anything
but authoring time.