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

Help with a Simple Question

P: n/a
Hi,

This is a newbie's question. I want to preload 4 images and only when
all 4 images has been loaded into browser's cache, I want to start a
slideshow() function. If images are not completed loaded into cache,
the slideshow doesn't look very nice.

I am not sure how/when to call the slideshow() function to make sure it
starts after the preload has been completed.

Thanks in advance for your help!

Terry

************************************************** ***********
<head>
<script language="JavaScript" type="text/JavaScript">
<!--
function MM_preloadImages() {
var d=document; if(d.images){ if(!d.MM_p) d.MM_p=new Array();
var i,j=d.MM_p.length,a=MM_preloadImages.arguments; for(i=0; i
<a.length; i++)
if (a[i].indexOf("#")!=0){ d.MM_p[j]=new Image; d.MM_p[j++].src=a
[i];}}
}

function slideshow() {

.....

}

//-->
</script>
</head>

<body onload="MM_preloadImages('01.jpg','02.jpg','03.jpg ','04.jpg')">
</body>
</html>
Jul 20 '05 #1
Share this Question
Share on Google+
16 Replies


P: n/a
In article <MP************************@news.tc.umn.edu>, Terry
<go**************@REMOVE.yahoo.com> writes:
This is a newbie's question. I want to preload 4 images and only when
all 4 images has been loaded into browser's cache, I want to start a
slideshow() function. If images are not completed loaded into cache,
the slideshow doesn't look very nice.

I am not sure how/when to call the slideshow() function to make sure it
starts after the preload has been completed.


load it via the window.onload or in the body tag:

window.onload = slideshow;

in the script section, or:

<body onload="slideshow()">

The page will not be considered "loaded" until the images are loaded as well.
--
Randy
Jul 20 '05 #2

P: n/a

load it via the window.onload or in the body tag:

window.onload = slideshow;

in the script section, or:

<body onload="slideshow()">

The page will not be considered "loaded" until the images are loaded as well.


Randy,

I did the above. However, the slideshow starts before all the images
are loaded.

Terry
Jul 20 '05 #3

P: n/a
Terry wrote:
load it via the window.onload or in the body tag:

window.onload = slideshow;

in the script section, or:

<body onload="slideshow()">

The page will not be considered "loaded" until the images are loaded as well.

Randy,

I did the above. However, the slideshow starts before all the images
are loaded.

Terry


<img src="image1.jpg" width="1" height="1">
<img src="image2.jpg" width="1" height="1">
<img src="image3.jpg" width="1" height="1">
<img src="image4.jpg" width="1" height="1">

and so on for each image. Then use the body's onload or window.onload to
start the slideshow.

Or, something is wrong with your preloading script. Post a URL to a
sample page if you can't get it working.

Jul 20 '05 #4

P: n/a
<img src="image1.jpg" width="1" height="1">
<img src="image2.jpg" width="1" height="1">
<img src="image3.jpg" width="1" height="1">
<img src="image4.jpg" width="1" height="1">

and so on for each image. Then use the body's onload or window.onload to
start the slideshow.

Or, something is wrong with your preloading script. Post a URL to a
sample page if you can't get it working.


Hi Randy, Thanks for your help!

http://free.hostdepartment.com/j/javashop/

Please take a look of the link if you have a minute. It has no problem
with fast internet connection. However, over 56k modem, I can see that
the slide show has started while down at the status bar, it says that X
number of images remained to be downloaded.

Terry
Jul 20 '05 #5

P: n/a
Randy,

http://free.hostdepartment.com/j/jav...reload_bar.htm

Can you take a look of this link as well? The slide show starts before
the image loading bar gets 100%.

I was wonder if there is way to call a function after the preloading
complete. I am not sure where to stick in the nextAd() -- the slideshow
function inside the image loading function.

Thanks again!

Terry
Jul 20 '05 #6

P: n/a
Terry wrote:
<img src="image1.jpg" width="1" height="1">
<img src="image2.jpg" width="1" height="1">
<img src="image3.jpg" width="1" height="1">
<img src="image4.jpg" width="1" height="1">

and so on for each image. Then use the body's onload or window.onload to
start the slideshow.

Or, something is wrong with your preloading script. Post a URL to a
sample page if you can't get it working.

Hi Randy, Thanks for your help!

http://free.hostdepartment.com/j/javashop/

Please take a look of the link if you have a minute. It has no problem
with fast internet connection. However, over 56k modem, I can see that
the slide show has started while down at the status bar, it says that X
number of images remained to be downloaded.


Thats because your preload routing happens after the page has loaded.

<body onload="MM_preloadImages(snipped for brevity), nextAd()">

Page loads.
Preload routine starts, images start downloading.
nextAd() starts.

If you are wanting to ensure that the images load before the routine
starts, then remove the preload from the onload, and load them during
page processing.

--
Randy

Jul 20 '05 #7

P: n/a
Thats because your preload routing happens after the page has loaded.

<body onload="MM_preloadImages(snipped for brevity), nextAd()">

Page loads.
Preload routine starts, images start downloading.
nextAd() starts.

If you are wanting to ensure that the images load before the routine
starts, then remove the preload from the onload, and load them during
page processing.


Thanks again Randy! It makes sense. Just to make sure I understand.
So if I put the following "preload" script in the <head> or <body> of a
page, the 2 images get loaded before any "onload" routines start?

During "page processing", do all the scripts embedded in <head> and
<body> get executed before "onload" routines?

<head>
<script type="text/javascript" language="JavaScript">

var bannerAD=new Array("images/01.jpg","images/02.jpg");

var preloadedimages=new Array();
for (i=0;i<bannerAD.length;i++){
preloadedimages[i]=new Image();
preloadedimages[i].src=bannerAD[i];
}
</script>
</head>
Jul 20 '05 #8

P: n/a
Terry wrote:
Thats because your preload routing happens after the page has loaded.

<body onload="MM_preloadImages(snipped for brevity), nextAd()">

Page loads.
Preload routine starts, images start downloading.
nextAd() starts.

If you are wanting to ensure that the images load before the routine
starts, then remove the preload from the onload, and load them during
page processing.

Thanks again Randy! It makes sense. Just to make sure I understand.
So if I put the following "preload" script in the <head> or <body> of a
page, the 2 images get loaded before any "onload" routines start?


Yes.
During "page processing", do all the scripts embedded in <head> and
<body> get executed before "onload" routines?
Depends on what they do. But for the most part, yes.
<head>
<script type="text/javascript" language="JavaScript">

var bannerAD=new Array("images/01.jpg","images/02.jpg");

var preloadedimages=new Array();
for (i=0;i<bannerAD.length;i++){
preloadedimages[i]=new Image();
preloadedimages[i].src=bannerAD[i];
}
</script>
</head>


In theory it does. In practice, I haven't seen a situation where that
doesn't work. Doesn't mean there isn't one though.

P.S. The language attribute is not needed, type="text/javascript" is
sufficient on its own.

--
Randy

Jul 20 '05 #9

P: n/a
Randy,

Thanks so much for your help! Here is a slightly off-subject question.
When I load the page, it seemed to me that images were loaded sequentially
based on their names. In other words, 01.jpg is loaded earlier than
logo.jpg. Am I imagining this or is it the order in which the images are
loaded onto a page?

Terry
Jul 20 '05 #10

P: n/a
Terry wrote:
Randy,

Thanks so much for your help! Here is a slightly off-subject question.
When I load the page, it seemed to me that images were loaded sequentially
based on their names. In other words, 01.jpg is loaded earlier than
logo.jpg. Am I imagining this or is it the order in which the images are
loaded onto a page?

Terry


You are imagining it. They are loaded in the order they appear. Whether
its in ABC order or not.

Please read the FAQ with regards to quoting.

--
Randy

Jul 20 '05 #11

P: n/a
Please read the FAQ with regards to quoting.


Randy,

I checked this link: http://jibbering.com/faq/
but didn't find anything there.

I would also like to understand how a browser decides what to do with
text, table, img, script ... on a page. Are there any resources on the
web that provide some info in this regard?

Thanks again for your generous help!

Terry
Jul 20 '05 #12

P: n/a
On Tue, 13 Jan 2004 15:36:19 -0600, Terry
<go**************@REMOVE.yahoo.com> wrote:
Please read the FAQ with regards to quoting.
Randy,

I checked this link: http://jibbering.com/faq/
but didn't find anything there.


I believe the relevant link was to http://www.ietf.org/rfc/rfc1855.txt (in
FAQ section 2.3). This document gives etiquette guidelines that should be
observed during communication on the Internet. The most appropriate advice
was:

"If you are sending a reply to a message or a posting be sure you
summarize the original at the top of the message, or include
just enough text of the original to give a context. This will
make sure readers understand when they start to read your
response. Since NetNews, especially, is proliferated by
distributing the postings from one host to another, it is
possible to see a response to a message before seeing the
original. Giving context helps everyone. But do not include
the entire original!"

Except from RFC 1855, Section 3.1.1, General Guidelines for
mailing lists and NetNews
I would also like to understand how a browser decides what to do with
text, table, img, script ... on a page. Are there any resources on the
web that provide some info in this regard?


Are you referring to the parsing of HTML, or its display once it's been
parsed?

Mike

--
Michael Winter
M.******@blueyonder.co.invalid (replace ".invalid" with ".uk" to reply)
Jul 20 '05 #13

P: n/a

Are you referring to the parsing of HTML, or its display once it's been
parsed?

Mike


Mainly parsing. Thanks Mike!

Terry
Jul 20 '05 #14

P: n/a
Terry wrote:
Please read the FAQ with regards to quoting.

Randy,

I checked this link: http://jibbering.com/faq/
but didn't find anything there.


http://jibbering.com/faq/#FAQ2_3
specifically, but the entire document.

2.3 deals with what/how to quote and what not to quote.
I would also like to understand how a browser decides what to do with
text, table, img, script ... on a page. Are there any resources on the
web that provide some info in this regard?


What resource you use would depend on what you are trying to find out.
And what browser you are researching.
--
Randy

Jul 20 '05 #15

P: n/a
On Tue, 13 Jan 2004 16:21:49 -0600, Terry
<go**************@REMOVE.yahoo.com> wrote:
Are you referring to the parsing of HTML, or its display once it's been
parsed?


Mainly parsing. Thanks Mike!


Be aware that I've never actually written a browser or a HTML parser. I
toyed with the idea a while ago, but by the end of this post, you'll
probably see why I decided against it. What I describe below would be my
approach, but as it hasn't been implemented, it could be seriously flawed.

If every HTML document on the WWW followed the W3C's HTML Recommendations
(the Standard) to the letter (very easy to do with a little effort and
some reading), parsing HTML would be really quite easy. One could follow
the DOM (Document Object Model) and build a hierarchical tree that
represented the structure of the document. Each node would be of a certain
type (table, paragraph, button, etc), and that gives the basic display
characteristics of the element. Each node would also hold the attributes
and stylesheet information that then modified those basic characteristics.

The tree would be simple to build. Every time a new HTML element is
encountered, it is added to the tree at the current 'depth'. If the new
element is a container of any kind[1], all subsequent elements are added
as children (they are at a lower depth). When a closing tag is
encountered, new elements will be added at a higher, previous depth. Take
the following document, for example (attributes and the DTD have been
omitted).

<HTML>
<HEAD>
<TITLE>A HTML Page</TITLE>
</HEAD>

<BODY>
<P>This is a demonstration page.
<TABLE>
<TR>
<TD>Cell 1
<TR>
<TD>Cell 2
</TABLE>
</BODY>
</HTML>

The tree representation would then look like this:

Document
+- Head
| +- Title
| +- (Text) A HTML Page
|
+- Body
+- P
| +- (Text) This is a demonstration page.
|
+- Table
+- TR
| +- TD
| +- (Text) Cell 1
|
+- TR
+- TD
+- (Text) Cell 2

Once built, the tree could be traversed from the top-down, building each
element as you go. Once enough information is available to begin rendering
(text in a paragraph, first complete cell or row in a table, etc), the
element can be displayed.

Unfortunately, the caveat that I mentioned at the beginning is very
important (and particularly relevant). From the point of view of the
Standard, the majority of HTML documents on the WWW don't conform at best,
and at worst they are complete gibberish. This has lead to the rise of
quirks-mode parsing, where the browser basically guesses what the author
wanted[2]. The simple treatment given to parsing above doesn't work with
invalid documents. One has to anticipate every little thing that a
would-be author might try to do, even if it makes absolutely no sense[3].

I don't know if that was what you were looking for, or if you wanted
something more specific (like how a particular browser parses documents).
In any case, it was an interesting thought exercise for me. :)

Mike
[1] Examples would be tables, forms and links (anything with an opening
and closing tag). The first two are block-level elements, so they are
containers by nature. A link is still a container of sorts, because it
holds text. Something like HR (horizontal rule), INPUT or BR (line break)
elements aren't containers because they are defined to be empty.

[2] This is probably acheived from experience; amateur webmasters might
e-mail browser developers asking why their pages don't render as they
wanted. This way developers can build a picture of common mistakes and
compensate for them automatically. Another approach would be to build
"what if" scenarios and decide what the best course of action would be if
an author missed some important information. A common example would be the
script language - the general response is to assume JavaScript.

[3] **Beware: rant** That's the general approach with all general user
applications but it's more complicated, in my mind, with parsing and why I
can't understand the attitude of some authors. I'm referring to the ones
that think that because browsers can parse rubbish, authors should write
rubbish and just let the browser sort it out. I'm certain that if browsers
didn't have to innately cope with ridiculous errors, they'd be faster and
a lot more stable. I realise that browsers would have to have basic
tolerance to handle typos and a lapse in concentration on the author's
part. However, a browser could simply ignore the erroneous mark-up and
flag an error (a pop-up or in-line, bold error text). When the author
checks the document with the browser (though a validator should be used to
check for errors), the problem is obvious and is then corrected. That's
what happens with most applications, so why not browsers?

--
Michael Winter
M.******@blueyonder.co.invalid (replace ".invalid" with ".uk" to reply)
Jul 20 '05 #16

P: n/a
On Wed, 14 Jan 2004 01:02:09 GMT, Michael Winter
<M.******@blueyonder.co.invalid> wrote:
If every HTML document on the WWW followed the W3C's HTML Recommendations
(the Standard) to the letter (very easy to do with a little effort and
some reading), parsing HTML would be really quite easy.
Well it would be easier, it would be far from easy, otherwise the HTML
validators who only need to be able to parse valid documents would be
a lot more bug free than they are.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01
Transitional//EN"><html><title/&lt;!--&gt;title>--&lt;chicken/body/h1>Jim

Valid document or not? and if it is, what does the DOM look like?
I realise that browsers would have to have basic
tolerance to handle typos and a lapse in concentration on the author's
part.
No, they either have to render everything no errors, or do their best
effort in all cases, you can't have partial error tolerance, that's
bad.
However, a browser could simply ignore the erroneous mark-up and
flag an error (a pop-up or in-line, bold error text).
That would be very bad, it doesn't matter if I make a spelling
mistake, or a grammar mistake in this message a human can understand
it, if I wrote complete gibberish they would realise this and note
both errors, the same happens with a browser. If the error is serious
the page will be such gibberish the user will know to disregard, if
there's simple but fixable errors, then they don't even need to know
about them.

There's no feedback loop in browsers, the reader can't get a page
fixed, so they shouldn't be prevented from seeing the content due to
an error in the content.

There is also the fact that all software is buggy, if a client gets
the parsing wrong (which is far from simple) then the author is stuck
in the position of a valid document which users cannot see. We need
invalid documents to render and we need error correction.
When the author
checks the document with the browser (though a validator should be used to
check for errors), the problem is obvious and is then corrected.
Unless the error is one which that browser doesn't detect through bugs
in its parsing.
That's
what happens with most applications, so why not browsers?


Browsers are different.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

Jul 20 '05 #17

This discussion thread is closed

Replies have been disabled for this discussion.