Any way to see if an img is done downloading?

D

dysfunct

Question: If I have a lot of <img> tags on a site, all linking from
all sorts of domains, is there a way to check to see which ones have
finished downloading and which ones haven't? For example let's say I
have

<div>
<img src="something.com/pic.jpg">
<img src="somethingelse.com/pic.jpg">
<img src="somethingelse.com/pic.jpg">
<img src="somethingelse.com/pic.jpg">
<img src="somethingelse.com/pic.jpg">
<img src="somethingelse.com/pic.jpg">
</div>

And I want to display a loading gif untill all the images are
completely downloaded. Is there a way to check?
 
T

Thomas 'PointedEars' Lahn

dysfunct said:
And I want to display a loading gif untill all the images are
completely downloaded.

That's completely pointless. The UA will not only have to download your
image switching script but also your "loading gif".
Is there a way to check?

At least not an interoperable or efficient one.


PointedEars
 
S

SAM

dysfunct a écrit :
Question: If I have a lot of <img> tags on a site, all linking from
all sorts of domains, is there a way to check to see which ones have
finished downloading and which ones haven't? For example let's say I
have

<div>
<img src="something.com/pic.jpg">
<img src="somethingelse.com/pic.jpg">
<img src="somethingelse.com/pic.jpg">
<img src="somethingelse.com/pic.jpg">
<img src="somethingelse.com/pic.jpg">
<img src="somethingelse.com/pic.jpg">
</div>

And I want to display a loading gif untill all the images are
completely downloaded. Is there a way to check?


<body onload="stopAnim();">
 
D

dysfunct

That's completely pointless. The UA will not only have to download your
image switching script but also your "loading gif".

Actually it's not pointless - suppose i just wasn't explaining it
enough. Let's say the div and all the img tags are added after the dom
is initially ready. Also, let's say there are 600 img tags and the
images are all between 100 and 300 kb. Now lets say that the setup is
more complicated than just a div with imgs in it, and the appearance
of the whole thing is contingent upon those images being downloaded
and displayed. So if the images take a total of (arbitrarily) 45
seconds to download, I don't want that portion of the page to look
terrible while the images are loading, so i want to show a simple
loading gif (say 10kb) instead until the images have finished.
 
E

endangeredmassa

Actually it's not pointless - suppose i just wasn't explaining it
enough. Let's say the div and all the img tags are added after the dom
is initially ready. Also, let's say there are 600 img tags and the
images are all between 100 and 300 kb. Now lets say that the setup is
more complicated than just a div with imgs in it, and the appearance
of the whole thing is contingent upon those images being downloaded
and displayed. So if the images take a total of (arbitrarily) 45
seconds to download, I don't want that portion of the page to look
terrible while the images are loading, so i want to show a simple
loading gif (say 10kb) instead until the images have finished.

If the size of the image is what makes the layout look proper, then
consider adding the height and width attributes to your image tags.
That way, they will occupy that much space before the image is loaded.

Another option would be to place divs instead of img tags, then use
AJAX requests to grab the images. You can then check the readyState to
see when the image has been downloaded and act accordingly--perhaps by
changing the innerHTML of the div element to have the img tag.
 
T

Thomas 'PointedEars' Lahn

That's completely pointless. The UA will not only have to download
your image switching script but also your "loading gif".
Actually it's not pointless - suppose i just wasn't explaining it
enough. Let's say the div and all the img tags are added after the dom
is initially ready. Also, let's say there are 600 img tags and the
images are all between 100 and 300 kb. [...]

It's even more idiotic to download all those images at once. That is why
thumbnails were invented.
If the size of the image is what makes the layout look proper, then
consider adding the height and width attributes to your image tags. That
way, they will occupy that much space before the image is loaded.

That's the only proper way.
Another option would be to place divs instead of img tags, then use AJAX
requests to grab the images. You can then check the readyState to see
when the image has been downloaded and act accordingly--perhaps by
changing the innerHTML of the div element to have the img tag.

That is not a viable option. In the worst case this will cause downloading
the image data twice. As I pointed out, the whole concept of an external
wait image for an image is dysfunctional (no offense meant).


PointedEars
 
L

Logos

Question: If I have a lot of <img> tags on a site, all linking from
all sorts of domains, is there a way to check to see which ones have
finished downloading and which ones haven't? For example let's say I
have

<div>
<img src="something.com/pic.jpg">
<img src="somethingelse.com/pic.jpg">
<img src="somethingelse.com/pic.jpg">
<img src="somethingelse.com/pic.jpg">
<img src="somethingelse.com/pic.jpg">
<img src="somethingelse.com/pic.jpg">
</div>

And I want to display a loading gif untill all the images are
completely downloaded. Is there a way to check?

Yes. <img> sort of supports the onload event. I think it's not a web
standard, but most browsers support it anyway. So you can do
something like

<img src='some pic' onload='register("some pic")' class='hideMe'>

where register() keeps track of the images and once the last one calls
it saying it's loaded, it goes thru the images and sets the class back
to something where they'll be visible and hides whatever your
placeholding image or progress bar is.

Tyler
 
T

Thomas 'PointedEars' Lahn

Logos said:
Yes. <img> sort of supports the onload event.

Just when you thought it couldn't get any worse ...
I think it's not a web standard,

It is not.
but most browsers support it anyway.

Utter nonsense.
So you can do something like
<img src='some pic' onload='register("some pic")' class='hideMe'>

That is invalid. Not only has the `img' element no `onload' attribute, the
`alt' attribute is required.
where register() keeps track of the images and once the last one calls
it saying it's loaded, it goes thru the images and sets the class back
to something where they'll be visible and hides whatever your
placeholding image or progress bar is.

So you would have to display the wait image first, and then display the
actual image. That would not work without client-side scripting, the wait
image would be displayed forever, the real image would not be indexed by
search engines et cetera et cetera. Great.


PointedEars
 
B

Bart Van der Donck

Thomas said:
That's completely pointless.  The UA will not only have to download your
image switching script but also your "loading gif".


At least not an interoperable or efficient one.

Sure there is. You simply use immature criteria to judge what's good
software and what's not.
 
T

Thomas 'PointedEars' Lahn

Bart said:
Sure there is.

Can you place your money where your mouth is? I doubt it.
You simply use immature criteria to judge what's good
software and what's not.

That's coming from someone who is unable to recognize the script-kiddie code
quality of

// wz_dragdrop.js:83
for(var dd_i = dd_cursors.length; dd_i;)
{--dd_i;
eval('var CURSOR_' +
(dd_cursors[dd_i].substring(2).toUpperCase().replace('-', '_')) + ' = "' +
dd_cursors[dd_i] + '";');
}


PointedEars
 
L

Logos

On Mar 5, 7:10 am, Thomas 'PointedEars' Lahn <[email protected]>
wrote:

My. Certainly a strongly opinionated fellow, aren't you?
Utter nonsense.

Please justify that statement. Otherwise it is simply noise fuzzing
out the signal. I've used it, and it works in the major browsers.
That is invalid. Not only has the `img' element no `onload' attribute, the
`alt' attribute is required.

The code is an off the cuff example, not professionally written
material for a production system. Obviously. Regardless, it still
works. As I am sure you are well aware, JS does not have strict
requirements about runtime validity / well-formed-ness (unlike, say,
XML). And, as I mentioned, img's onload is not a web standard but it
is still supported by most browsers.
So you would have to display the wait image first, and then display the
actual image. That would not work without client-side scripting,

Yup. Oddly enough, most people use JS for client side scripting.
Very weird that that should be a solution presented for a question
asked on a JS newsgroup, eh? And yes, some people don't have JS
turned on in their browsers.

Well, screw 'em! Heh. Either that, or use JS to hide the images
while they're loading by plonking a short inline script after each
image to tweak it's style attributes and a similar code snippet to
show the 'please wait' image. I'm not here to work out all the
details on how to make the page mechanics robust - he can do that
himself, and if he needs help with it he can ask again. I'm here to
address the original question (and now to argue with you)

the wait
image would be displayed forever,

It would not for most browsers. As I've said, I've used img onload
before, and it works. We don't live in a perfect world - not
everything is to standard, nor are standards necessarily reflective of
reality.

the real image would not be indexed by
search engines et cetera et cetera. Great.

:shrug: Wasn't a consideration in the original question, and I doubt
most people care whether Google images shows up your pics. The show/
hide inline scripts I mentioned above would take care of that too.
Even so, I have no clue if bots would think that that was cloaking or
not; that's a question for the search engine people. Are you an SEO
expert, out of curiosity?

Sincerely trying to be helpful rather than obstructive, pompous and
condescending,
Tyler

Tyler
 
T

Thomas 'PointedEars' Lahn

Logos said:
My. Certainly a strongly opinionated fellow, aren't you?

Unlike some other people, I know what I am talking about and am not afraid
to say so.
Please justify that statement. Otherwise it is simply noise fuzzing out
the signal. I've used it, and it works in the major browsers.

I did not debate that. However, I did debate that there was a *majority* of
browsers. This cannot be known, so a statement regarding that is nonsense.
It deserves to be called utter nonsense if said statement is used as an
argument to justify a design decision, like here.
The code is an off the cuff example, not professionally written material
for a production system. Obviously.

Invalid examples are usually useless and potentially harmful. For example,
they may be copied as-is by the uninitiated and make the Web even of worse
code quality than it is today. It is my impression that the active
scubscribers of this newsgroup want to add to knowledge and help with
unlearning false knowledge with their postings instead.
Regardless, it still works.

It works for you, in the limited set of browsers that you could have tested
with.
As I am sure you are well aware, JS does not have strict requirements
about runtime validity / well-formed-ness (unlike, say, XML). And, as I
mentioned, img's onload is not a web standard but it is still supported
by most browsers.

Wrong on all accounts.
Yup. Oddly enough, most people use JS for client side scripting. Very
weird that that should be a solution presented for a question asked on a
JS newsgroup, eh?

Unlike the script-kiddie Web forums that you may know, this technical
newsgroup is subscribed to and kept alive by experienced people who
recommend a reasonable use of the language. Especially in a Web context
that includes the concept of graceful degradation: Client-side scripting
should add to the experience of a Web site, not replace it. And certainly
a Web site should not break or become inaccessible if client-side script
support was not available.
And yes, some people don't have JS turned on in their browsers.

And for some people that won't even make a difference, because the script is
filtered out elsewhere or there UA did not support JS in the first place.
You are well-advised to read previous discussions before saying anything
more about this subject.
Well, screw 'em! Heh.

It rather screws you, being ignorant about the wishes of your visitors,
potential customers and bosses.
It would not for most browsers.

Even if that statement was true, it was irrelevant entirely.
As I've said, I've used img onload before, and it works.

See above.
We don't live in a perfect world - not everything is to standard, nor are
standards necessarily reflective of reality.

Ah, the washed-out "real world" killer argument; I wondered when that would
happen here. JFYI: Using a feature unnecessarily that is known not to work
always, and to be harmful, where there is a better alternative -- even if
that alternative means not to use the language discussed here -- is just
plain stupid.


PointedEars
 
L

Logos

Unlike some other people, I know what I am talking about and am not afraid
to say so.



I did not debate that. However, I did debate that there was a *majority* of
browsers. This cannot be known, so a statement regarding that is nonsense.
It deserves to be called utter nonsense if said statement is used as an
argument to justify a design decision, like here.



Invalid examples are usually useless and potentially harmful. For example,
they may be copied as-is by the uninitiated and make the Web even of worse
code quality than it is today. It is my impression that the active
scubscribers of this newsgroup want to add to knowledge and help with
unlearning false knowledge with their postings instead.


It works for you, in the limited set of browsers that you could have tested
with.


Wrong on all accounts.



Unlike the script-kiddie Web forums that you may know, this technical
newsgroup is subscribed to and kept alive by experienced people who
recommend a reasonable use of the language. Especially in a Web context
that includes the concept of graceful degradation: Client-side scripting
should add to the experience of a Web site, not replace it. And certainly
a Web site should not break or become inaccessible if client-side script
support was not available.


And for some people that won't even make a difference, because the script is
filtered out elsewhere or there UA did not support JS in the first place.
You are well-advised to read previous discussions before saying anything
more about this subject.


It rather screws you, being ignorant about the wishes of your visitors,
potential customers and bosses.



Even if that statement was true, it was irrelevant entirely.


See above.


Ah, the washed-out "real world" killer argument; I wondered when that would
happen here. JFYI: Using a feature unnecessarily that is known not to work
always, and to be harmful, where there is a better alternative -- even if
that alternative means not to use the language discussed here -- is just
plain stupid.

PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

<shrug> The gentleman asked a question, and I answered it. I don't
feel that I've been called to stand in judgment of what he wants or
how he does it. I saw a question I could contribute to, and I tried
to help. You, on the other hand, have merely delivered condescending
commentary without actually providing any *help*. You told him what
he wanted to do was pointless and inefficient based on your own views
and ideas, which is fine although you were IMHO somewhat unpleasant
about it and in follow up posts, but then you didn't offer any actual
constructive advice. Criticism like that is not constructive, and
regardless of whether you feel you know what you are talking about,
you still have to back up what you're saying in a post. No first time
or infrequent poster is going to read thru the entire newsgroup just
to establish your street cred.

Aaaaaand we're done feeding the trolls for the day!
 
T

Thomas 'PointedEars' Lahn

Logos said:

Please trim your quotes. http://jibbering.com/faq/
<shrug> The gentleman asked a question, and I answered it. I don't feel
that I've been called to stand in judgment of what he wants or how he
does it. I saw a question I could contribute to, and I tried to help.

But you did not help. You gave bad advice and have been corrected.
You, on the other hand, have merely delivered condescending commentary
without actually providing any *help*.

This is not a support forum. BTW, just in case you don't happen to know,
this is not a Web forum either.
You told him what he wanted to do was pointless and inefficient based on
your own views and ideas,

Based on my experience and well-founded opinion, yes.
which is fine although you were IMHO somewhat unpleasant about it

I am not afraid to call nonsense "nonsense", if that is what you mean.
and in follow up posts, but then you didn't offer any actual constructive
advice. Criticism like that is not constructive,

Quite the contrary. Sometimes the best advice is the recommendation not to
do something.
and regardless of whether you feel you know what you are talking about,
you still have to back up what you're saying in a post.

I have backed it up several times now. This is a *news*group.
No first time or infrequent poster is going to read thru the entire
newsgroup just to establish your street cred.

This is not about me, it is about giving good advice, and bad advice
incidentally coming from you.
Aaaaaand we're done feeding the trolls for the day!

Who is the troll here, who engages in side arguments, who is attacking the
person instead of providing a solid argumentation for his opinion, is pretty
clear by now. Go away.


PointedEars
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,755
Messages
2,569,534
Members
45,008
Latest member
Rahul737

Latest Threads

Top