By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,729 Members | 1,490 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,729 IT Pros & Developers. It's quick & easy.

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

P: n/a
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.

Oct 25 '07 #1
Share this Question
Share on Google+
23 Replies


P: n/a
Sa***********@gmail.com wrote:
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.
Oct 25 '07 #2

P: n/a
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>

Oct 25 '07 #3

P: n/a
Sa***********@gmail.com wrote:
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
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
Oct 25 '07 #4

P: n/a
>
Please don't.
Thank you very much in advance for any assistance.:)

You're welcome.

F'up2 cljs
What?

Oct 25 '07 #5

P: n/a
Sa***********@gmail.com wrote:
<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.
Oct 25 '07 #6

P: n/a
On Oct 25, 5:45 pm, SaraLeePer...@gmail.com wrote:
Please don't.
Thank you very much in advance for any assistance.:)
You're welcome.
F'up2 cljs

What?
Follow up to comp.lang.javascript.

As for the original question, if these images are displayed initially
without user interaction, then trying to preload them is a waste of
time. The page will continue to render, regardless of whether the
images have finished loading. This is a good thing.

I don't know what you mean by "flicker", but if your layout twitches
during load, you likely forgot the height/width attributes on the
images.

Or perhaps they are interlaced GIF's and you don't like that effect.
If so, make them non-interlaced.

If it is the placeholders that bug you and these images are just
decorations, use CSS to make them backgrounds.

Oct 25 '07 #7

P: n/a
On Oct 25, 11:50 am, SaraLeePer...@gmail.com wrote:
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
Oct 26 '07 #8

P: n/a
On Fri, 26 Oct 2007 00:25:53 GMT Peter Michaux wrote:
>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.
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.

--
Bone Ur
Cavemen have stronger pheromones.
Oct 28 '07 #9

P: n/a
On Oct 27, 10:02 pm, Bone Ur <bon...@example.comwrote:
On Fri, 26 Oct 2007 00:25:53 GMT Peter Michaux wrote:


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.

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.

Oct 28 '07 #10

P: n/a
Well bust mah britches and call me cheeky, on Sun, 28 Oct 2007 08:57:45 GMT
David Mark scribed:
>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.
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.

--
Bone Ur
Cavemen have stronger pheromones.
Oct 29 '07 #11

P: n/a
In article <Xn**********************************@85.214.62.10 8>,
Neredbojias <mo*************@yahoo.comwrote:
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.

--
dorayme
Oct 29 '07 #12

P: n/a
Bone Ur wrote:
>
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.

--
Berg
Oct 29 '07 #13

P: n/a
Well bust mah britches and call me cheeky, on Mon, 29 Oct 2007 19:32:36 GMT
dorayme scribed:
>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.
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
Just a boogar in the proboscis of life.
Oct 29 '07 #14

P: n/a
Well bust mah britches and call me cheeky, on Mon, 29 Oct 2007 20:00:51
GMT Bergamot scribed:
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.
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.
>As for semantics - phffft! Very few pages have correct semantics,

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.

--
Neredbojias
Just a boogar in the proboscis of life.
Oct 29 '07 #15

P: n/a
Neredbojias wrote:
Well bust mah britches and call me cheeky, on Mon, 29 Oct 2007 20:00:51
GMT Bergamot scribed:
>You might be surprised how many sites I have to disable CSS on just so
I can read them,

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

--
Berg
Oct 29 '07 #16

P: n/a
In article <Xn**********************************@85.214.62.10 8>,
Neredbojias <mo*************@yahoo.comwrote:
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?

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.

--
dorayme
Oct 29 '07 #17

P: n/a
Well bust mah britches and call me cheeky, on Mon, 29 Oct 2007 21:16:41 GMT
Bergamot scribed:
Neredbojias wrote:
>Well bust mah britches and call me cheeky, on Mon, 29 Oct 2007 20:00:51
GMT Bergamot scribed:
>>You might be surprised how many sites I have to disable CSS on just so
I can read them,

Not relevant.

?
I wasn't responding to one of your posts, but to one by Bone Ur.
Oh. Sorry, I didn't realize it was a closed conversation.

--
Neredbojias
Just a boogar in the proboscis of life.
Oct 30 '07 #18

P: n/a
Well bust mah britches and call me cheeky, on Mon, 29 Oct 2007 21:53:40 GMT
dorayme scribed:
>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?

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.
Guess what? This message does _not_ appear on Motzarella. I suspected
some items were missing; that's why I adopted a dual presence to check.

Anyway, about your misconception, some things are always sacrificed when
you break new ground. The trick is not to sacrifice unnecessarily or use
it as an excuse to be less-than-proficient. I'm not advocating ignoring
accessibility, but I do state that practical considerations may cause some
compromise.
--
Bone Ur
Cavemen have formidable pheromones.
Oct 30 '07 #19

P: n/a
Well bust mah britches and call me cheeky, on Tue, 30 Oct 2007 07:24:01
GMT Neredbojias scribed:
>>>You might be surprised how many sites I have to disable CSS on just
so I can read them,

Not relevant.

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

Oh. Sorry, I didn't realize it was a closed conversation.
You old dog!

--
Bone Ur
Cavemen have formidable pheromones.
Oct 30 '07 #20

P: n/a
Neredbojias wrote:
Well bust mah britches and call me cheeky, on Mon, 29 Oct 2007 21:16:41 GMT
Bergamot scribed:
>Neredbojias wrote:
>>>
Not relevant.

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

Oh. Sorry, I didn't realize it was a closed conversation.
Sorry, that wasn't really my point. I was responding to some specific
statements made by Bone Ur. Your comments on my statements didn't really
relate to those, at least not that I could figure out, hence the "?". I
thought perhaps you were replying to the wrong post. It does happen to
some people occasionally.

If you were referencing something else in another part of this thread,
then *your* reply was not relevant to my comments. BTW, I still don't
get what you said, as related to what I said.

--
Berg
Oct 30 '07 #21

P: n/a
On 30 Oct, 17:19, Bone Ur <bon...@example.comwrote:
Well bust mah britches and call me cheeky,
Explains a lot.

"Bone Ur" and "Neredbojias" are parts of the same [...]
so plonk to you too then
Oct 30 '07 #22

P: n/a
Well bust mah britches and call me cheeky, on Tue, 30 Oct 2007 18:23:23 GMT
Andy Dingley scribed:
On 30 Oct, 17:19, Bone Ur <bon...@example.comwrote:
>Well bust mah britches and call me cheeky,

Explains a lot.

>"Bone Ur" and "Neredbojias" are parts of the same [...]

so plonk to you too then
Phffft!

--
Bone Ur
Cavemen have formidable pheromones.
Oct 30 '07 #23

P: n/a
On 30 Oct, 17:19, Bone Ur <bon...@example.comwrote:
Well bust mah britches and call me cheeky,
Explains a lot.
"Bone Ur" and "Neredbojias" are parts of the same [...]
so plonk to you too then
Oct 31 '07 #24

This discussion thread is closed

Replies have been disabled for this discussion.