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

preloader not working

P: n/a
This page I am trying to create a preloader that hides all the other content
except the hidepage div until it loads...any ideas?

Or any preloaders that actually work?
http://www.nssdesign.scot.nhs.uk/home/index.php


--
Posted via NewsDemon.com - Premium Uncensored Newsgroup Service
------->>>>>>http://www.NewsDemon.com<<<<<<------
Unlimited Access, Anonymous Accounts, Uncensored Broadband Access
Jan 5 '06 #1
Share this Question
Share on Google+
8 Replies


P: n/a
Ross wrote:
This page I am trying to create a preloader that hides all the
other content except the hidepage div until it loads...any ideas?


(I do not know if you try to preload images or simple want to hide the
content until it is fully loaded [which is no preloading whatsoever],
so my reply addresses both.)

Do not walk into this pitfall in the first place, like I once did. Consider
how this approach will affect the responsiveness of your site/document,
especially on slower machines and slower Internet connections. You do not
know how the document will be accessed and you cannot change that; you do
not know the cache settings and you cannot change them either, so you do
not even know that the advantage of speeding up the display process later
is worth the big disadvantage of slowing it down first by possible
synchronous requests due to preloading. Users tend to be quite impatient
when resources are loaded (ref. World Wide Waiting), and they will leave if
it takes too long.

Therefore, any preloader should be triggered onload the `body' element of
the document that contains the data to be preloaded, so that _hopefully_
preloading is done asynchronously and does not interfere with what users
expect: that the document is loaded step by step and they can at least see,
if not access, already loaded content while the rest is still loading.

This means if you simply want to hide all the document's content until it is
fully loaded, just do not do it. A reasonable approach is to display the
"please stand by" or whatever message somewhere where it would not even
interfere with the content if CSS was not supported. And then there is URL
prefetching which works without client-side scripting on supporting UAs --
where, last but not least, client-side scripting can be disabled or not
even be supported anyway and a preloader would not even work.
HTH

PointedEars
Jan 5 '06 #2

P: n/a
Ross wrote:
This page I am trying to create a preloader that hides all the other content
except the hidepage div until it loads...any ideas?

Or any preloaders that actually work?
http://www.nssdesign.scot.nhs.uk/home/index.php
That page contains a number of markup and script errors. Use a
browser with a JavaScript console or other debugging techniques to fix
them.

<URL:http://validator.w3.org/check?uri=http%3A%2F%2Fwww.nssdesign.scot.nhs.uk%2 Fhome%2Findex.php>
Until you fix the markup, the W3C CSS validator will not validate your
page. However, errors:

There is no CSS property called "layer-background-color"

100opx is not a valid value for a div height
Your 'pre-load' script is:
<SCRIPT LANGUAGE="JavaScript">
Tag and attribute names in XHTML must be lower case. The language
attribute is deprecated, type is required:

<script type="text/javascript">

<!-- Begin
HTML comment delimiters in XHTML should hide the entire contents of
the script, even from script engines. Most will ignore it, but you
should not count on non-standard behaviour.

<URL:http://www.w3.org/TR/xhtml1/#h-4.8>

Use:

<script type="text/javascript">
<![CDATA[
... unescaped script content ...
]]>
</script>
function loadImages() {
if (document.getElementById) { // DOM3 = IE5, NS6
document.getElementById('hidepage').style.visibili ty = 'hidden';
Having tested getElementById, you should also test that the style
object is supported too.

}
else {
if (document.layers) { // Netscape 4
Here is a syntax error, you have too many braces ({). Remove one
brace and put all three lines in one:

} else if (document.layers) { // Netscape 4

document.hidepage.visibility = 'hidden';
}
else { // IE 4
document.all.hidepage.style.visibility = 'hidden';
}
Remove the extra brace.

}
}
// End -->
Replace this comment too.

</script>

Your body tag starts with:
<body OnLoad="loadImages()">
As noted above, in XHTML all tag and attribute names must be in lower
case, so:

<body onload="loadImages()">
will keep the validator happy.
Your script is futile anyway - it doesn't preload anything. It just
tries to hide the page until the HTML has finished loading.
What do you expect this script to do:
<script type="text/javascript">
javascrip:ts('body', 3)
if (document.getElementById("one").style.color ="#FFFFFF")
</script>

All it does for me is throw an error.

--
Rob
Jan 5 '06 #3

P: n/a
VK

RobG wrote:
Use:

<script type="text/javascript">
<![CDATA[
... unescaped script content ...
]]>
</script>


....which may cause a problem in Firefox 1.5 as soon as content type is
changed to HTML (or even as it is):
<http://developer.mozilla.org/en/docs/E4X>

So either:

<script type="text/javascript;e4x=1">
<![CDATA[
... unescaped script content ...
]]>
</script>

or:

<script type="text/javascript"><!--
... unescaped script content ...
--></script>

or (best of all):

<script type="text/javascript">
... script content as it is
</script>

That's just a neverending story with comments - and now Mozilla
Foundation decided to add some more fun :-( :-)

Jan 5 '06 #4

P: n/a
VK wrote:
RobG wrote:
Use:

<script type="text/javascript">
<![CDATA[
... unescaped script content ...
]]>
</script>

...which may cause a problem in Firefox 1.5 as soon as content type is
changed to HTML (or even as it is):
<http://developer.mozilla.org/en/docs/E4X>

So either:

<script type="text/javascript;e4x=1">
<![CDATA[
... unescaped script content ...
]]>
</script>

or:

<script type="text/javascript"><!--
... unescaped script content ...
--></script>

or (best of all):

<script type="text/javascript">
... script content as it is
</script>


Yes, I meant to include a comment to say just use HTML and forget
commenting out scripts altogether. But a few other errors distracted
me... :-)

--
Cheers, Rob
Jan 5 '06 #5

P: n/a
VK wrote:
RobG wrote:
Use:

<script type="text/javascript">
<![CDATA[
... unescaped script content ...
]]>
</script>
...which may cause a problem in Firefox 1.5 as soon as content type is
changed to HTML (or even as it is):


It is perfectly Valid XHTML that is understood as specified by Firefox 1.5
(and all other XHTML-capable Geckos, that would exclude only ) if declared
as such (using "<!DOCTYPE ...>") and served as either text/html or
application/xhtml+xml.
<http://developer.mozilla.org/en/docs/E4X>
E4X is completely irrelevant here.
[...]
or:

<script type="text/javascript"><!--
... unescaped script content ...
--></script>
No, don't.
or (best of all):

<script type="text/javascript">
... script content as it is
</script>
Yes, for HTML. For XHTML, the best way is to put the script element's
content into a different resource, serve it as text/javascript and refer
to that resource using the `script' element's `src' element.
That's just a neverending story with comments - and now Mozilla
Foundation decided to add some more fun :-( :-)


CDATA declarations are not comments, and E4X is a Good Thing, being
Standard ECMA-357 BTW.

<URL:http://pointedears.de/scripts/js-version-info#ecmascript>

Please stop talking about things where you have no minimum clue.
PointedEars
Jan 5 '06 #6

P: n/a
Thomas 'PointedEars' Lahn wrote:
VK wrote:
RobG wrote:
Use:

<script type="text/javascript">
<![CDATA[
... unescaped script content ...
]]>
</script>
...which may cause a problem in Firefox 1.5 as soon as content type is
changed to HTML (or even as it is):


It is perfectly Valid XHTML that is understood as specified by Firefox 1.5
(and all other XHTML-capable Geckos, that would exclude only ) if declared

^ as such (using "<!DOCTYPE ...>") and served as either text/html or
application/xhtml+xml. [...]


Sorry, forgot to include the results of my research :)

ISTM that Mozilla/5.0 Milestone 3 already supported XHTML. M3 (1999-03-19)
to M8 (1999-07-16) Release Notes[1] say about "Available Gecko
functionality":

| Extensible Markup Language (XML)
|
| * James Clark expat parser in; documents parse.
| * Simple XLink and HTML Namespaces done.
^^^^^^^^^^^^^^^
And the milestone plan for Mozilla already mentions MathML support in
version 0.6 (2000-12-06), for which full XHTML support is required (as
MathML can be "embedded" in XHTML 1.1).
PointedEars
___________
[1] <URL:http://www.mozilla.org/projects/seamonkey/release-notes/>
[2] <URL:http://www.mozilla.org/releases/milestones.html>
Jan 5 '06 #7

P: n/a
VK

Thomas 'PointedEars' Lahn wrote:
VK wrote:
RobG wrote:
Use:

<script type="text/javascript">
<![CDATA[
... unescaped script content ...
]]>
</script>


...which may cause a problem in Firefox 1.5 as soon as content type is
changed to HTML (or even as it is):


It is perfectly Valid XHTML that is understood as specified by Firefox 1.5
(and all other XHTML-capable Geckos, that would exclude only ) if declared
as such (using "<!DOCTYPE ...>") and served as either text/html or
application/xhtml+xml.
<http://developer.mozilla.org/en/docs/E4X>


E4X is completely irrelevant here.


Your sincretism (habit to apply facts from all different sources and
contexts in one heap) hits you sometimes.

I tried to explain several times already that [CDATA[ has nothing to do
with HTML - it's XML beast (plus XHTML pervertion which is something in
between of both). So no browser is obligated to understand this
declaration within HTML context, and no browser cares if something
exists in SGML, PHP, Perl, Java etc. - but outside of the declated
context.

<http://developer.mozilla.org/en/docs/E4X>
<quote>
In Gecko 1.8 based browsers such as Firefox 1.5, E4X is already
partially enabled for web page authors. To fully enable E4X, the
<script> element needs to have the MIME type "text/javascript;e4x=1"
(i.e. have an attribute of the form type="text/javascript;e4x=1"). The
difference between the two modes is that without the "e4x=1" MIME type,
any statement-level XML/HTML comment literals (<!--...-->) are ignored
for backwards compatibility with the comment hiding trick, and CDATA
sections (<![CDATA[...]]>) are not parsed as CDATA literals (which
leads to a JS syntax error in HTML since HTML does not support CDATA
sections).
</quote>

Sample 1 (all samples for Firefox 1.5)
<html>
<head>
<title>JavaScript</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<script type="text/javascript">
<![CDATA[
function test() {
alert('OK');
}
]]>
</script>

</head>

<body onload="test()">

</body>
</html>
Result: "syntacs error" in JavaScript Console

Sample 2
<html>
<head>
<title>JavaScript</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<script type="text/javascript;e4x=1">
<![CDATA[
function test() {
alert('OK');
}
]]>
</script>

</head>

<body onload="test()">

</body>
</html>
Result: no errors, no execution (ignored as CDATA)

Jan 5 '06 #8

P: n/a
VK wrote:
Thomas 'PointedEars' Lahn wrote:
VK wrote:
> RobG wrote:
>> Use:
>>
>> <script type="text/javascript">
>> <![CDATA[
>> ... unescaped script content ...
>> ]]>
>> </script>
>
> ...which may cause a problem in Firefox 1.5 as soon as content type is
> changed to HTML (or even as it is): It is perfectly Valid XHTML that is understood as specified by Firefox
1.5 (and all other XHTML-capable Geckos, that would exclude only ) if
declared as such (using "<!DOCTYPE ...>") and served as either text/html
or application/xhtml+xml.
> <http://developer.mozilla.org/en/docs/E4X>


E4X is completely irrelevant here.


Your sincretism (habit to apply facts from all different sources and
contexts in one heap) hits you sometimes.


But not here.
I tried to explain several times already that [CDATA[ has nothing to do
with HTML -
True, yet E4X is still completely irrelevant here.
it's XML beast
True.
(plus XHTML pervertion which is something in
between of both).
Rubbish. XHTML is an XML application. XML rules apply to
XHTML, that includes CDATA declarations.
So no browser is obligated to understand this
declaration within HTML context,


And I did not state in any way it should. Learn to read.
PointedEars
Jan 5 '06 #9

This discussion thread is closed

Replies have been disabled for this discussion.