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

<noscript> alternative for random image changer

P: n/a
Afaik the use of a <noscriptelement is frowned upon nowadays. For a JS
random image changer I tried to use a replacement by having the script
change the HTML src attribute value of an img element. The trouble is
that in some situations like over slow connections (on initial load when
the JS is in an external file), or with a slow client the image
specified in the HTML starts to load and display before it's changed by
the script. This I'm not happy with.

Simplified demo:
http://homepage.ntlworld.ie/spartani...lternative.htm

Using a solution like using CSS to initially switch the display of the
image off, then enable it again via JS makes the solution dependant on
JS, so that's out (and it can cause an ugly reflow).

Is there a way to prevent this problem?

--
Spartanicus
Jul 26 '06 #1
Share this Question
Share on Google+
7 Replies


P: n/a
Spartanicus <in*****@invalid.invalidwrote:
Afaik the use of a <noscriptelement is frowned upon nowadays.
<question rhetorical="no">
Why would that be so?
</question>

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.
Jul 26 '06 #2

P: n/a
Christopher Benson-Manica said the following on 7/26/2006 2:57 PM:
Spartanicus <in*****@invalid.invalidwrote:
>Afaik the use of a <noscriptelement is frowned upon nowadays.

<question rhetorical="no">
Why would that be so?
</question>
Because there are better, more dependable, alternatives to it.

The <noscriptelement lends itself to attempting to explain why you had
to make script dependent pages. Make your pages script independent, then
use script to enhance them. When you start doing that, you will find
yourself asking "Why did I ever use it to begin with?"

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Jul 26 '06 #3

P: n/a
Spartanicus wrote:
<snip>
Using a solution like using CSS to initially switch the display
of the image off, then enable it again via JS makes the solution
dependant on JS, so that's out (and it can cause an ugly reflow).
You can certainly avoid the dependency on javascript by having an inline
script initially hide the contents as the page is loading and then
re-show the contents in the onload event handler. So if the scripting
cannot initially hide the contents they are never hidden, which is the
correct outcome as the inability to hide them should reflect an
inability to reveal them again later.

Re-flowing is a slightly more difficult question, but using
visibility:hidden; in pace of display:none; may stop the user from
seeing the elements until after they re-flow (following whatever DOM
manipulation your script is planning.

Richard.
Jul 26 '06 #4

P: n/a
Christopher Benson-Manica wrote:
Spartanicus <in*****@invalid.invalidwrote:
>Afaik the use of a <noscriptelement is frowned upon
nowadays.

<question rhetorical="no">
Why would that be so?
</question>
When a scripted web page arrives at a browser there are 3 main
possibilities:-

1. The browser is capable of executing scripts, scripting is enabled
and the browser fully supports all the facilities and features
needed by the script in order for it to act as intended.
2. The browser is incapable of executing scripts or scripting in
disabled. The script will not be able to act at all. (the contents
of NOSCRIPT elements will be dispalyed.)
3. The browser supports scripting and it is enabled, but it does not
provide all the features and facilities required by the script (or
its scripting language is not the one used by the script (unlikely
but possible)). The script will not be able to act (either through
choice or because it errors out, the later being avoidable with
appropriate feature detection testing).

The NOSCRIPT element accommodates the second possibility, with the
acting script accommodating the first. This (near) mutually exclusive
relationship between scripting being enabled and the use of the contents
of the NOSCRIPT element does not address the third possibility. However,
scripts/pages/systems designed for clean-degradation to viable
underlying HTML when a browser does not provide the required scriptable
features/facilities does accommodate the third possibility, and because
a script not being able to act because of a browser's lack of support
for needed features is not distinct from a script not being able to act
because scripting is disabled/unavailable the second possibility is also
accommodated. Thus designing for clean degradation accommodates all the
possibilities while the use of the NOSCRIPT element leaves one
undressed.

Any design that disregards such a significant known possibility is
incomplete, and so the use of NOSCRIPT elements is indicative of
incomplete script design.

Richard.
Jul 26 '06 #5

P: n/a
"Richard Cornford" <Ri*****@litotes.demon.co.ukwrote:
>Using a solution like using CSS to initially switch the display
of the image off, then enable it again via JS makes the solution
dependant on JS, so that's out (and it can cause an ugly reflow).

You can certainly avoid the dependency on javascript by having an inline
script initially hide the contents as the page is loading and then
re-show the contents in the onload event handler.
That would solve one of the problems I described (an external JS file
loading after the HTML page). But it doesn't solve the other case (a
slow client). Using Opera or Firefox I see the first image being
displayed before it is replaced by the script in the example I provided
which uses in document script code.

--
Spartanicus
Jul 26 '06 #6

P: n/a
Spartanicus wrote:
"Richard Cornford" <Ri*****@litotes.demon.co.ukwrote:
>>Using a solution like using CSS to initially switch
the display of the image off, then enable it again
via JS makes the solution dependant on JS, so that's
out (and it can cause an ugly reflow).

You can certainly avoid the dependency on javascript by
having an inline script initially hide the contents as
the page is loading and then re-show the contents in the
onload event handler.

That would solve one of the problems I described (an
external JS file loading after the HTML page). But it
doesn't solve the other case (a slow client). Using Opera
or Firefox I see the first image being displayed before it
is replaced by the script in the example I provided which
uses in document script code.
I think you are being pessimistic. Try this (you will have to provide
your own images):-

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title></title>
</head>
<style type="text/css">
IMG {
float:right;
}
</style>
<body>
<script type="text/javascript">
/* The body should be defined at this point so make
it invisible if it can be found:-
*/
if(
(document.body)&&
(document.body.style)
){
document.body.style.visibility = 'hidden';
window.onload = function(){
var img, c, div;
/* "Gateway" test for the required features:-
*/
if(
(document.images)&&
(c = document.images.length)&&
(img = document.images[--c])&&
(img.appendChild)&&
(img.removeChild)&&
(document.createElement)
){
/* Re-arrange the DOM and deprive the images of their
float styles, so that any rendering prior to the
re-arrangement is apparent. This takes the place of
your script initialisation code:-
*/
do{
img.style.cssFloat = img.style.styleFloat = 'none';
div = document.createElement('DIV');
document.body.appendChild(div);
div.appendChild(img);
}while(img = document.images[--c]);
}
/* Make the body visible again, regardless of the success of
the DOM re-arrangement as the user will still need to see
the content:-
*/
document.body.style.visibility = '';
}
}
</script>
<img src="images/grid50x50_Cyan.gif">
<img src="images/grid50x50_Cyan_K.gif">
<img src="images/grid50x50_Cyan_P.gif">
<img src="images/grid50x50_Cyan_Y.gif">
<img src="images/grid50x50_Mag.gif">
<img src="images/grid50x50_Mag_K.gif">
<img src="images/grid50x50_Mag_P.gif">
<img src="images/grid50x50_Mag_Y.gif">
<img src="images/grid50x50_Yellow.gif">
<img src="images/grid50x50_Yellow_K.gif">
<img src="images/grid50x50_Yellow_P.gif">
<img src="images/grid50x50_Yellow_Y.gif">
</body>
</html>

Richard.
Jul 26 '06 #7

P: n/a
"Richard Cornford" <Ri*****@litotes.demon.co.ukwrote:
>>You can certainly avoid the dependency on javascript by
having an inline script initially hide the contents as
the page is loading and then re-show the contents in the
onload event handler.

That would solve one of the problems I described (an
external JS file loading after the HTML page). But it
doesn't solve the other case (a slow client). Using Opera
or Firefox I see the first image being displayed before it
is replaced by the script in the example I provided which
uses in document script code.

I think you are being pessimistic. Try this (you will have to provide
your own images):-
[snip code example]

Sorry that code is to far above my skill level.

Before posting I experimented with using CSS display:none or
visibility:hidden and then negating that with the script, it got rid of
the initial image being displayed by Opera, but not Firefox.

Also, using the visibility property prevents a reflow, but it doesn't
prevent the image from being retrieved, in fact neither does
display:none in certain browsers IIRC.

--
Spartanicus
Jul 26 '06 #8

This discussion thread is closed

Replies have been disabled for this discussion.