Screen question

**Evertjan.** · Jul 20 '05, 11:01 AM

Re: Screen question

Al wrote on 08 okt 2003 in comp.lang.javas cript:[color=blue]
> Can I turn on/off the browser's screen updating until the entire page
> is loaded ? i.e. is it possible to show a page only when it is
> completely in browser's memory ? I don't want to show a object one by
> one when downloading a page.[/color]

<body onload="mydiv.s tyle.display='' ">
<div id="mydiv" style="display: none;">
===<br>
===<br>
===<br>
===<br>
===<br>
All contents of the page here<br>
===<br>
===<br>
===<br>
===<br>
===
</div>
</body>

=============== ====

onload=.. really means "on page loaded"

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

**David Dorward** · Jul 20 '05, 11:01 AM

Re: Screen question

Evertjan. wrote:
[color=blue]
> Al wrote on 08 okt 2003 in comp.lang.javas cript:[color=green]
>> Can I turn on/off the browser's screen updating until the entire page
>> is loaded ? i.e. is it possible to show a page only when it is
>> completely in browser's memory ? I don't want to show a object one by
>> one when downloading a page.[/color]
>
>
> <body onload="mydiv.s tyle.display='' ">
> <div id="mydiv" style="display: none;">[/color]

This is two side effects...

(1) If the user doesn't have JavaScript enabled, but does have CSS enabled,
they won't see the content - ever.

(2) If the user doesn't happen to be using a browser with the non-standard
"all ids automatically become global variables" thing, they will again, see
nothing.

--
David Dorward http://dorward.me.uk/

**Evertjan.** · Jul 20 '05, 11:01 AM

Re: Screen question

David Dorward wrote on 08 okt 2003 in comp.lang.javas cript:[color=blue]
> Evertjan. wrote:
>[color=green]
>> Al wrote on 08 okt 2003 in comp.lang.javas cript:[color=darkred]
>>> Can I turn on/off the browser's screen updating until the entire
>>> page is loaded ? i.e. is it possible to show a page only when it is
>>> completely in browser's memory ? I don't want to show a object one
>>> by one when downloading a page.[/color]
>>
>>
>> <body onload="mydiv.s tyle.display='' ">
>> <div id="mydiv" style="display: none;">[/color]
>
> This is two side effects...
>
> (1) If the user doesn't have JavaScript enabled, but does have CSS
> enabled, they won't see the content - ever.[/color]

I think you should see my code as a pointer in the right direction.
Of cource you can improve on it by also hiding the div by javascript in
the <head> section.
[color=blue]
> (2) If the user doesn't happen to be using a browser with the
> non-standard "all ids automatically become global variables" thing,
> they will again, see nothing.[/color]

Personally I always use getElementById.

Again, I think code given in this NG should be NOT used "copy, paste and
no need to understand", but just showing that it can be done.

==============

Furthermore it is the personal choice of the page builder, if he wants to
accommodate for non-IE browsers and for javascript off. [Or only for NS,
for that matter] That does not mean I think it a bad thing that you warn
for these matters in my code. You are welcome to do that.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

**Richard Cornford** · Jul 20 '05, 11:02 AM

Re: Screen question

"Evertjan." <exjxw.hannivoo rt@interxnl.net > wrote in message
news:Xns940ED2D F438ECeejj99@19 4.109.133.29...[color=blue]
>David Dorward wrote on 08 okt 2003 in comp.lang.javas cript:[color=green]
>> Evertjan. wrote:[/color][/color]
<snip>[color=blue][color=green][color=darkred]
>>><body onload="mydiv.s tyle.display='' ">
>>> <div id="mydiv" style="display: none;">[/color]
>>
>>This is two side effects...
>>
>>(1) If the user doesn't have JavaScript enabled, but does
>>have CSS enabled, they won't see the content - ever.[/color]
>
>I think you should see my code as a pointer in the
>right direction.[/color]

That assumes it is the right direction. The OP's problem seems to be the
progressive rendering of HTML so there might be HTML structures that
could be used on the page that would prevent the browser from doing
progressive rendering. That would of course be a question best addressed
to an HTML group but if it can be done then the JavaScript dependency
would become totally avoidable.
[color=blue]
>Of cource you can improve on it by also hiding the
>div by javascript in the <head> section.[/color]

Except that it is not quite as simple as just using JavaScript to
document.write a style element in to the head section as some browsers,
even with JavaScript enables, just cannot switch the CSS display
property of an element with JavaScript so the browser's support for that
ability would have to be ascertained prior to the writing of the style
element. (and directly setting style.display = 'none'; in the head won't
work because the DIV would not exist at that point).
[color=blue][color=green]
>>(2) If the user doesn't happen to be using a browser
>>with the non-standard "all ids automatically become
>>global variables" thing, they will again, see nothing.[/color]
>
>Personally I always use getElementById.[/color]

Then why do you frequently post code that assumes IDs will be global
properties?
[color=blue]
>Again, I think code given in this NG should be NOT used
>"copy, paste and no need to understand",[/color]

There is considerably more to Internet browser scripting than just
writing code, so providing copy-n-paste code without explanation would
be doing nobody any favours. If posted code has issues then it has got
to be worth mentioning them.
[color=blue]
>but just showing that it can be done.[/color]

Consider the not infrequently enquired about desire to read and write
files on the user's computer over the Internet. It can be done and the
code to do it could be posted, but there are so many ifs associated with
attempting to do it that in practice it is impractical.

There is a big difference between what can be done and what should be
done, especially when what can be done can only be done on one browser
in a very specific configuration.
[color=blue]
>Furthermore it is the personal choice of the page builder,
>if he wants to accommodate for non-IE browsers and for
>javascript off. [Or only for NS, for that matter] That
>does not mean I think it a bad thing that you warn for
>these matters in my code. You are welcome to do that.[/color]

It should not really be necessary for other people to be pointing out
issues with your code. But because you author exclusively for JScript
enabled default configurations of IE running on default configurations
of Windows OSs and don't even consider the alternative, you are just
unaware of most of the issues associated with the code you post to this
group.

Obviously that is your decision but as the default assumption for this
group is that questions asked relate to cross-browser scripting for the
Internet (unless stated otherwise, as noted in the FAQ) much higher
standards than yours are expected here.

Of course the simplest solution would be for you to add the caveat that
to the best of your knowledge all the code you post will only work
successfully on JScript enabled default configurations of Windows IE (or
whatever more specific warning best describes your situation), and leave
it to the OP (and others) to judge what value to place on the
accompanying contribution for themselves.

Richard.

**Evertjan.** · Jul 20 '05, 11:02 AM

Re: Screen question

Richard Cornford wrote on 09 okt 2003 in comp.lang.javas cript:
[color=blue][color=green]
>>Of cource you can improve on it by also hiding the
>>div by javascript in the <head> section.[/color]
>
> Except that it is not quite as simple as just using JavaScript to
> document.write a style element in to the head section as some
> browsers, even with JavaScript enables, just cannot switch the CSS
> display property of an element with JavaScript so the browser's
> support for that ability would have to be ascertained prior to the
> writing of the style element. (and directly setting style.display =
> 'none'; in the head won't work because the DIV would not exist at that
> point).[/color]

You are right there, I did not think of that.
[color=blue][color=green]
>>Personally I always use getElementById.[/color]
>
> Then why do you frequently post code that assumes IDs will be global
> properties?[/color]

Because I am lazy and want to get to the point quickly.
Perhaps your response will cure me.
[color=blue][color=green]
>>Again, I think code given in this NG should be NOT used
>>"copy, paste and no need to understand",[/color]
>
> There is considerably more to Internet browser scripting than just
> writing code, so providing copy-n-paste code without explanation would
> be doing nobody any favours. If posted code has issues then it has got
> to be worth mentioning them.[/color]

Here we agree.
[color=blue][color=green]
>>Furthermore it is the personal choice of the page builder,
>>if he wants to accommodate for non-IE browsers and for
>>javascript off. [Or only for NS, for that matter] That
>>does not mean I think it a bad thing that you warn for
>>these matters in my code. You are welcome to do that.[/color]
>
> It should not really be necessary for other people to be pointing out
> issues with your code. But because you author exclusively for JScript
> enabled default configurations of IE running on default configurations
> of Windows OSs and don't even consider the alternative, you are just
> unaware of most of the issues associated with the code you post to
> this group.[/color]

What I code for some of my own pages is not the same as what I show in
this NG. But even so many how-to issues are far more interesting than the
finesses of cross browser or cross version relyability.
[color=blue]
> Obviously that is your decision but as the default assumption for this
> group is that questions asked relate to cross-browser scripting for
> the Internet (unless stated otherwise, as noted in the FAQ) much
> higher standards than yours are expected here.
>
> Of course the simplest solution would be for you to add the caveat
> that to the best of your knowledge all the code you post will only
> work successfully on JScript enabled default configurations of Windows
> IE (or whatever more specific warning best describes your situation),
> and leave it to the OP (and others) to judge what value to place on
> the accompanying contribution for themselves.[/color]

I try not to post jscript specific code in this NG, but do not expect me
to have my examples cross platform tested. Usually I try to add "IE6
tested".

And please do not expect me to be an expert. I get far more from this NG
than I give.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

**Richard Cornford** · Jul 20 '05, 11:03 AM

Re: Screen question

"Evertjan." <exjxw.hannivoo rt@interxnl.net > wrote in message
news:Xns940FA7B E78905eejj99@19 4.109.133.29...[color=blue][color=green][color=darkred]
>>>Of cource you can improve on it by also hiding the
>>>div by javascript in the <head> section.[/color]
>>
>>Except that it is not quite as simple as just using JavaScript to
>>document.writ e a style element in to the head section as some
>>browsers, even with JavaScript enables, just cannot switch the CSS
>>display property of an element with JavaScript so the browser's
>>support for that ability would have to be ascertained prior to the
>>writing of the style element. (and directly setting style.display =
>>'none'; in the head won't work because the DIV would not exist
>>at that point).[/color]
>
> You are right there, I did not think of that.[/color]

There does appear to be a correlation between - typeof x.style.display
== 'string' - and a browser's ability to dynamically switch the display
state of an element. But the style.display property of the DIV would
still not exist at this point so to test within the head it would be
necessary to test the style.display property of an element that did
exist at that point, such as the title, or the script element itself.
Fortunately, the browsers on which you cannot access the head elements
(or don't have style objects on elements) also cannot switch the display
state of an element, so a positive - typeof x.style.display ==
'string' - might be used to justify writing out a new style element
with - #mydiv { display:none; } - or similar.

That would clearly be code that made and inference based on an
assumption, not something that should be done in cross-browser scripting
without a very good reason.

Thinking more about the OP's problem, I wonder if it doesn’t actually
come down to an inefficient server script, dribbling HTML into the
response while it does a lot of complex work (database references and
calculation). In which case the real solution might be to do all the
complex work and pre-building the HTML (or critical sections of it)
before starting to output anything, so the response would be an
uninterrupted stream of HTML. In which case it probably would not be too
important if the browser progressively rendered it as it arrived, even
if it was a large page, as the user would probably still not have time
to read the first screen full before the download and rendering was
finished.

Another case where knowing why something was wanted (including details
of the context) may have suggested other approaches that would avoid any
JavaScript dependency.

<snip>[color=blue]
>... . Usually I try to add "IE6 tested".[/color]
<snip>

Add the work "only" and you probably will never get comments about code
not being cross-browser. But still maybe suggestions about making it
more cross-browser, cleaner degrading, reliable and/or more general.

Richard.

**Evertjan.** · Jul 20 '05, 11:03 AM

Re: Screen question

Richard Cornford wrote on 10 okt 2003 in comp.lang.javas cript:[color=blue]
> Another case where knowing why something was wanted (including details
> of the context) may have suggested other approaches that would avoid any
> JavaScript dependency.[/color]

Context is everything.

Then again, just a clientsided javascript answer is not uncommon or
illogical in this NG.

;-}

Many a problem can better be delt with serverside, making the cross browser
issue a minor issue. But telling this to a OP that potentially has no
serverside code access could be quite rude.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

Screen question

Screen question

Comment

Comment

Comment

Comment

Comment

Comment

Comment