Delaying viewing of the document
pembeci
I am using JavaScript to modify some text parts of a loaded document. The
functions are loaded from a file at the header and run by:
<body onLoad="...">
According to the the Venkman profile the scripts run in a total of 170
milliseconds. However, when I load the page I can see the original form
of the document (original text) and I can observe the text change. So is
there a way to block the browser from displaying the document until
scripts are done?
Thanks.
Joakim Braun
news:220937eb14fc577e...@localhost.talkaboutprogramming.com...
Having the <body> invisible to begin with (using CSS), then making it
visible at the end of the script?
(those with JS turned off won't see anything at all then, of course)
Joakim Braun
pembeci
I tried this but couldn't get it work:
<body onload="loadAll(); all.display='';">
<div id="all" style="display:none">
Can I access 'all' like this?
Secondly, what shall I set display to make it visible?
Thanks.
pembeci
pembeci
Fred Oz
> I mean all.style.display=' '
>
or do you mean:
document.getElementById('all').style.display='none';
I would also be wary of using an id like 'all', it's a bit close to a
keyword (IE's document.all from JScript), so use a name with some
capitalisation that couldn't possibly be one, such as 'aDiv' or 'theDiv'
or similar.
Cheers, Fred.
RobG
> pembeci wrote:
>
>> I mean all.style.display=' '
>>
>
> or do you mean:
>
> document.getElementById('all').style.display='none';
>
Close...
document.getElementById('all').style.display='none';
will hide "all" (sets display to 'none'),
document.getElementById('all').style.display='';
will show "all" (sets display to an empty string, so it has
the default behaviour which is to display stuff).
Rob
Dr John Stockton
ogramming.com>, dated Sun, 3 Oct 2004 07:00:23, seen in
news:comp.lang.javascript, pembeci <pem...@cs.jhu.edu> posted :
As stated, not entirely a good idea; if the delay is imperceptible, it's
pointless, and if it is noticeable, readers may lose hope before it is
finished.
Presuming that your document uses, or can be set to use, [near-]black
text on a [near-]white ground, you can do (pseudo-HTML/JS) :-
<body>
This is my page; be patient
<script> document.bgColor = "black" </script>
<p>Waffle
<script> for (j=0;j<1000000;j++) {} </script>
<p>Waffle
<script> document.bgColor= "white" </script>
<p>End of computed text
</body>
Except, of course, that the colour of a DIV should be changed, and not
that of the whole document.
The delay is about 3 s in a PII/300; for test, some may prefer a larger
count.
Note that using script to make it invisible means that if scripting is
off the stuff will be visible.
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
Philip Ronan
> <script> for (j=0;j<1000000;j++) {} </script>
(snip)
> The delay is about 3 s in a PII/300; for test, some may prefer a larger
> count.
I think that's the worst bit of advice I've ever seen in this NG.
--
Philip Ronan
phil.r...@virgin.net
(Please remove the "z"s if replying by email)
Randy Webb
> On 3/10/04 11:08 pm, Dr John Stockton wrote:
>
>
>><script> for (j=0;j<1000000;j++) {} </script>
>
>
> (snip)
>
>
>>The delay is about 3 s in a PII/300; for test, some may prefer a larger
>>count.
>
>
> I think that's the worst bit of advice I've ever seen in this NG.
>
With setTimeout and setInterval, I have to agree with you.
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq
Dr John Stockton
Oct 2004 23:46:07, seen in news:comp.lang.javascript, Philip Ronan
<phil.r...@virgin.net> posted :
>On 3/10/04 11:08 pm, Dr John Stockton wrote:
>
>> <script> for (j=0;j<1000000;j++) {} </script>
>
>(snip)
>
>> The delay is about 3 s in a PII/300; for test, some may prefer a larger
>> count.
>
>I think that's the worst bit of advice I've ever seen in this NG.
Why? It's only a simple demonstration delay, not for use in the final
page; it represents, by consuming time in a script, time /in lieu/ of
the time that the OP says will be consumed by his script. Anything
fancy would be inferior, for the immediate purpose.
Anyone who cannot tolerate, in a development environment, the loss of 3
seconds CPU time will be smart enough to deal with the situation.
Method setTimeout can be used to get the desired visual effect, but
would not satisfy the OP's need.
Please re-configure, if you can, your attribution line date to something
internationally unambiguous; and preferably grammatical - in English,
"On date", but "At time".
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/> - see 00index.htm
Dates - miscdate.htm moredate.htm js-dates.htm pas-time.htm critdate.htm etc.
Philip Ronan
Stockton wrote:
> JRS: In article <BD863FBF.22D6B%phil.r...@virgin.net>, dated Sun, 3
> Oct 2004 23:46:07, seen in news:comp.lang.javascript, Philip Ronan
> <phil.r...@virgin.net> posted :
>> I think that's the worst bit of advice I've ever seen in this NG.
>
>
> Why? It's only a simple demonstration delay, not for use in the final
> page;
Well what use is that? One would assume the OP wanted something that would
work on a publicly accessible web page. That is, after all, what Javascript
is normally used for.
> it represents, by consuming time in a script, time /in lieu/ of
> the time that the OP says will be consumed by his script. Anything
> fancy would be inferior, for the immediate purpose.
What do you mean by "fancy"? Would you describe the use of an appropriate
built-in function like setTimeout() as fancy? Or how about a more
intelligent solution where the text-computing code calls a function to make
the text visible as soon as it has finished running, *however* long it
takes?
> Anyone who cannot tolerate, in a development environment, the loss of 3
> seconds CPU time will be smart enough to deal with the situation.
Since when was this discussion about a development environment?
> Method setTimeout can be used to get the desired visual effect, but
> would not satisfy the OP's need.
And you think making the browser sit and count up to a million is a better
answer?!? I'm not even convinced your method will even work as intended, but
I'll be darned if I'm going to waste my time trying it out.
> Please re-configure, if you can, your attribution line date to something
> internationally unambiguous; and preferably grammatical - in English,
> "On date", but "At time".
I'll see what I can do....
Dr John Stockton
Oct 2004 19:18:39, seen in news:comp.lang.javascript, Philip Ronan
<phil.r...@virgin.net> posted :
>On the 4th of October 2004 AD at 4:52 PM (British Summer Time), Dr John
>Stockton wrote:
>
>> JRS: In article <BD863FBF.22D6B%phil.r...@virgin.net>, dated Sun, 3
>> Oct 2004 23:46:07, seen in news:comp.lang.javascript, Philip Ronan
>> <phil.r...@virgin.net> posted :
>>> I think that's the worst bit of advice I've ever seen in this NG.
>>
>>
>> Why? It's only a simple demonstration delay, not for use in the final
>> page;
>
>Well what use is that? One would assume the OP wanted something that would
>work on a publicly accessible web page. That is, after all, what Javascript
>is normally used for.
I presented that pseudo-code after "you can do"; I left it to the OP to
make the obvious deductions about adapting it to his page. The line to
which you object is a mere stand-in for the OP's own time-consuming
code; it will not occur in the OP's proper page. Your reasoning is
faulty, and your objection incomprehensible.
>> it represents, by consuming time in a script, time /in lieu/ of
>> the time that the OP says will be consumed by his script. Anything
>> fancy would be inferior, for the immediate purpose.
>
>What do you mean by "fancy"? Would you describe the use of an appropriate
>built-in function like setTimeout() as fancy? Or how about a more
>intelligent solution where the text-computing code calls a function to make
>the text visible as soon as it has finished running, *however* long it
>takes?
That is exactly what will happen when the line is replaced by "real"
time-consuming code; the line directly follows the time-consuming part,
and will be executed immediately after it. A function is not
*required*.
>> Anyone who cannot tolerate, in a development environment, the loss of 3
>> seconds CPU time will be smart enough to deal with the situation.
>
>Since when was this discussion about a development environment?
That is, formally or informally, what the OP will be using while
developing his page. He presumably only offers it to the public once he
is reasonably satisfied with the operation of the current set of
changes.
>> Method setTimeout can be used to get the desired visual effect, but
>> would not satisfy the OP's need.
>
>And you think making the browser sit and count up to a million is a better
>answer?!? I'm not even convinced your method will even work as intended, but
>I'll be darned if I'm going to waste my time trying it out.
But, because you have not troubled to think the situation through, you
waste the time of the rest of us. No-one, AFAIR, asked you to try it
out.
>> Please re-configure, if you can, your attribution line date to something
>> internationally unambiguous; and preferably grammatical - in English,
>> "On date", but "At time".
>
>I'll see what I can do....
I can hardly have written that much in a single minute; I use "posted"
rather than "wrote".
--
Š John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME Š
Web <URL:http://www.uwasa.fi/~ts/http/tsfaq.html> -> Timo Salmi: Usenet Q&A.
Web <URL:http://www.merlyn.demon.co.uk/news-use.htm> : about usage of News.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.
rh
<...>
>
> I presented that pseudo-code after "you can do"; I left it to the OP to
> make the obvious deductions about adapting it to his page. The line to
> which you object is a mere stand-in for the OP's own time-consuming
> code; it will not occur in the OP's proper page. Your reasoning is
> faulty, and your objection incomprehensible.
>
Phil's reasoning is fine and his objection is perfectly
understandable. Your advice, whether given for a test (which was not
specified, and should have been if that were the case), or otherwise,
is in this instance well below the standard normally set by regular
responders, including yourself, in this group.
He outlined the intelligent solution (i.e. set the visibility once the
script had finished modifications) which would have properly fit with
the OP's request for assistance with dynamic presentation, and would
totally obviate the need for a test versus production version.
Instead of acknowledging a superior solution, you've persisted in
attempting to defend a piece of rather abysmal programming advice. As
a result, the OP is likely shaking his head wondering what kind of
warp he haplessly wandered into. And could be that that's only one
part of the pity.
../rh
Dr John Stockton
dated Tue, 5 Oct 2004 20:59:29, seen in news:comp.lang.javascript, rh
<codeH...@yahoo.ca> posted :
>Dr John Stockton wrote:
><...>
>>
>> I presented that pseudo-code after "you can do"; I left it to the OP to
>> make the obvious deductions about adapting it to his page. The line to
>> which you object is a mere stand-in for the OP's own time-consuming
>> code; it will not occur in the OP's proper page. Your reasoning is
>> faulty, and your objection incomprehensible.
>>
>
>Phil's reasoning is fine and his objection is perfectly
>understandable. Your advice, whether given for a test (which was not
>specified, and should have been if that were the case), or otherwise,
>is in this instance well below the standard normally set by regular
>responders, including yourself, in this group.
It is obviously a test or demonstration, rather than a complete
solution; some modicum of intelligence is expected of readers in a
technical newsgroup. The loop is clearly a CPU-using, time-consuming
loop; anything with setTimeout would only confuse..
>He outlined the intelligent solution (i.e. set the visibility once the
>script had finished modifications) which would have properly fit with
>the OP's request for assistance with dynamic presentation, and would
>totally obviate the need for a test versus production version.
Which is exactly what my code does, except that the time-consuming part
does not do anything useful other than to enable the two display
settings to be seen.
The OP wanted the contents not to be visible until a time-consuming
process had completed; that is what my demo does.
Note that by sending an intrinsically readable page and rendering it
unreadable by javascript, one can be reasonably sure that it can when
required be made visible by script. Joakim noted the flaw in his
response, with a pre-invisible body.
Those presenting methods with getElementById should note that it is not
always initially available, but can be provided (FAQ notes?).
Randy Webb
<--snip-->
> Those presenting methods with getElementById should note that it is not
> always initially available, but can be provided (FAQ notes?).
Only in certain browsers that do not support getElementById. IE4 allows
the semi-emulation, but NN4 does not. Not easily anyway.
rh
>rh <codeH...@yahoo.ca> posted :
> >Dr John Stockton wrote:
> ><...>
> >>
> >> I presented that pseudo-code after "you can do"; I left it to the OP to
> >> make the obvious deductions about adapting it to his page. The line to
> >> which you object is a mere stand-in for the OP's own time-consuming
> >> code; it will not occur in the OP's proper page. Your reasoning is
> >> faulty, and your objection incomprehensible.
> >>
> >
> >Phil's reasoning is fine and his objection is perfectly
> >understandable. Your advice, whether given for a test (which was not
> >specified, and should have been if that were the case), or otherwise,
> >is in this instance well below the standard normally set by regular
> >responders, including yourself, in this group.
>
> It is obviously a test or demonstration, rather than a complete
> solution; some modicum of intelligence is expected of readers in a
> technical newsgroup.
The issue here has little to do with whether your proposal is
complete, or whether intelligence needs to be applied to realize
something that "works" from it. The issue is that it is the wrong
solution.
>The loop is clearly a CPU-using, time-consuming
> loop;
And that is precisely why it's the wrong solution. "eval" has been
thoroughly debased in this group (and without doubt, rightly so) --
using a CPU leech to cause a time delay is orders of magnitude worse
than eval.
>anything with setTimeout would only confuse..
>
Read Phil's response carefully and you'll find that, while he didn't
have any problem with the use of setTimeout, he suggested that it
would not be necessary in an intelligent approach to effect the
requested result. So who's confused?
> >He outlined the intelligent solution (i.e. set the visibility once the
> >script had finished modifications) which would have properly fit with
> >the OP's request for assistance with dynamic presentation, and would
> >totally obviate the need for a test versus production version.
>
> Which is exactly what my code does, except that the time-consuming part
> does not do anything useful other than to enable the two display
> settings to be seen.
>
The time-consuming part is where the problem lies. Loops to create a
time delay:
a) make the browser unresponsive
b) take resources away from the browser that might otherwise
be usefully deployed in acquiring and rendering the page
c) take resources away from the system that might otherwise
be usefully deployed
d) are highly unreliable as a timing mechanism
In other words, loops to create time delays, regardless of duration,
are a really bad idea. Moreover, they are a particularly bad idea in
systems that are event-driven.
> The OP wanted the contents not to be visible until a time-consuming
> process had completed; that is what my demo does.
>
It doesn't matter. It's the wrong way to do it.
>
> Note that by sending an intrinsically readable page and rendering it
> unreadable by javascript, one can be reasonably sure that it can when
> required be made visible by script. Joakim noted the flaw in his
> response, with a pre-invisible body.
>
And you've noted in a previous response what needs to be done, by
those with "some modicum of intelligence", to avoid the problem.
../rh
Dr John Stockton
<codeH...@yahoo.ca> posted :
>
>The issue here has little to do with whether your proposal is
>complete, or whether intelligence needs to be applied to realize
>something that "works" from it. The issue is that it is the wrong
>solution.
>
>>The loop is clearly a CPU-using, time-consuming
>> loop;
>
>And that is precisely why it's the wrong solution.
The loop is part of the demonstration. It is not part of the solution
itself. It is to be replaced by the OP's time-consuming stuff.
Before the loop, the page is made unreadable. After the loop, the page
is made readable. With the loop replaced by what the OP wants to do,
the effect will be more or less what the OP wants.
Let us see your complete demonstration.
rh
>
> The loop is part of the demonstration. It is not part of the solution
> itself. It is to be replaced by the OP's time-consuming stuff.
>
OK, that explains a lot, and makes it almost forgivable. ;-)
> Before the loop, the page is made unreadable. After the loop, the page
> is made readable. With the loop replaced by what the OP wants to do,
> the effect will be more or less what the OP wants.
>
More or less. A couple of further things about it:
-- I believe you'll find that it doesn't behave as you expect in
Gecko-based browsers (i.e., there is no background setting
effect, so the text remains visible)
-- the notification text, advising the user to be patient, remains
visible in the final presentation (with Javascript enabled or
disabled)
> Let us see your complete demonstration.
<body onload="showNotice()">
<div id="main">
<textarea id="txt"> This is an initial test value </textarea>
</div>
<div id="notice" style="position:absolute;top:50px;left:100px;font-weight:bold;display:none">
Please wait...
</div>
<script type="text/javascript">
function getEl( n ) {
return document.getElementById && document.getElementById( n )
|| document.all && document.all[ n ] || { style : "" } ;
}
function setStyle( n, str, val ) { getEl( n ).style[ str ] = val;}
function setPage( ) {
//
// Page setup computation goes here, e.g.,
getEl( "txt" ).value = "Test completed";
//
setStyle( "main", "visibility", "visible" );
setStyle( "notice", "display", "none" );
}
function showNotice( ) {
setStyle( "notice", "display", "block" );
setStyle( "main", "visibility", "hidden" );
setTimeout( 'setPage()', 3000 ); /* 3 second demonstration
interval ... set to 0 when setPage computes values*/
}
</script>
</body>
../rh
Thomas 'PointedEars' Lahn
> [...] However, when I load the page I can see the original form
> of the document (original text) and I can observe the text change. So is
> there a way to block the browser from displaying the document until
> scripts are done?
Yes, there is, but don't attempt to do that. Why not?
For example, I am still such a technique to hide the entire document content
until it has finished loading, see <http://pointedears.de/ufpdb/main> and
select any entry in the index (there are still bugs, though).
However, I had to recognize that what I thought was a pretty cool feature
(considering the context it was used in) turned out to be a real headache:
Assuming that client-side scripting is present, if the document grows (like
Data's personnel file) or the connection speed degrades for some reason,
the user had to wait for text he would not have to wait for without the
script: the topmost paragraphs. That's why I am going to change my
documents and scripts so that loading the content of the document is no
longer blocked as the "loading ..." message is displayed in another frame.
PointedEars
--
"You have to mount it before you fsck it."
Thomas 'PointedEars' Lahn
> [...] However, when I load the page I can see the original form
> of the document (original text) and I can observe the text change. So is
> there a way to block the browser from displaying the document until
> scripts are done?
Yes, there is, but don't attempt to do that. Why not?
For example, I am still using such a technique to hide the
entire document content until it has finished loading, see
<http://pointedears.de/ufpdb/main> and select any entry in
the index (there are still bugs, though).
However, I had to recognize that what I thought was a pretty
cool feature (considering the context it was used in), turned
out to be a real headache: Assuming that client-side scripting
is present, if the document grows (like Data's personnel file)
or the connection speed degrades for some reason, the user has