When do scripts in document head execute?

  • Thread starter Manfred Kooistra
  • Start date
M

Manfred Kooistra

If I have a document like this:

<html>
<head>
<script language=javascript>
window.location.href='file.php';
</script>
</head>
<body>
body content
</body>
</html>

will the JavaScript in the head execute before the body loads, or will
the visitor see a short flash of the content before the new page loads?
 
M

McKirahan

Manfred Kooistra said:
If I have a document like this:

<html>
<head>
<script language=javascript>
window.location.href='file.php';
</script>
</head>
<body>
body content
</body>
</html>

will the JavaScript in the head execute before the body loads, or will
the visitor see a short flash of the content before the new page loads?
Click to expand...

1) Did you try it?

2) What behavior do you want?

If you want to go to another page immediately, you can do this:

<html>
<head>
<title>1.htm</title>
</head>
<body onload="window.location.href='file.php';">
body content
</body>
</html>

Or this:

<html>
<head>
<title>2.htm</title>
<script type="text/javascript">
window.onload = function () {
window.location.href='file.php';
}
</script>
</head>
<body>
body content
</body>
</html>

Or even this (which doesn't require that JavaScript be enabled):

<html>
<head>
<title>3.htm</title>
<meta http-equiv="refresh" content="0;
URL=http://{your-domain}/file.php';">
</head>
<body>
body content
</body>
</html>

But why would you?
 
R

RobG

Manfred said:
If I have a document like this:

<html>
<head>
<script language=javascript>
window.location.href='file.php';
</script>
</head>
<body>
body content
</body>
</html>

will the JavaScript in the head execute before the body loads,
Click to expand...

It is global code and should execute immediately it is encountered.
or will
the visitor see a short flash of the content before the new page loads?
Click to expand...

That is likely to be browser dependent - the page may continue to load
while waiting for the new request to be answered, or it may stop.
Testing will confirm.
 
R

Randy Webb

McKirahan said the following on 1/3/2007 7:19 PM:
1) Did you try it?

2) What behavior do you want?

If you want to go to another page immediately, you can do this:

<html>
<head>
<title>1.htm</title>
</head>
<body onload="window.location.href='file.php';">
body content
</body>
</html>
Click to expand...

That code doesn't "go to another page immediately", it waits for the
page to finish loading then it tries to go to another page. The code
originally posted will try to go to another page immediately though.
Or this:

<html>
<head>
<title>2.htm</title>
<script type="text/javascript">
window.onload = function () {
window.location.href='file.php';
}
</script>
</head>
<body>
body content
</body>
</html>
Click to expand...

Same as above.
Or even this (which doesn't require that JavaScript be enabled):
Click to expand...

But it does require that META Redirects be enabled in IE (where it can
be explicitly disabled).
 
M

Manfred Kooistra

Thank you so far.

Let me explain: I want to test wether JavaScript is enabled or disabled
in the visitor's browser and serve two different pages accordingly.
Since I cannot do this serverside I need to test it by executing a
script: if it executes, JavaScript is enabled; if it does not execute,
JavaScript is disabled.

So, if JavaScript is enabled, my script redirects to an alternative
page where the content offers JavaScript functionality, while, if
JavaScript is disabled, the current basic page (without JavaScript)
loads and is displayed.

I definitely do not want a flash of content, as this is ugly and
irritating to the visitor.

As Randy Webb already pointed out, McKirahan's first two examples won't
do the trick, since "onload" executes after the page is loaded, and the
meta refesh tag in the third example does not test for JavaScript (and
may be turned off, which makes relying on it impossible).

RobG's guess that the code "should execute immediately" doesn't really
help me. I don't have the environment to test all prossible browsers
and configurations. What I need is to definitely exit the current page
as soon as the script is loaded.

Is there an "exit" or "die" function in JavaScript (as there is in
serverside scripting)?
 
M

Manfred Kooistra

Manfred said:
Is there an "exit" or "die" function in JavaScript (as there is in
serverside scripting)?
Click to expand...

Well, obviously that was a stupid question :) A server executes a
script and does not display anything, so it can be "stopped", while a
browser's job is to load a page - and only then and only maybe execute
scripts on it.

There is indeed a "stop" function in JavaScript:
http://developer.mozilla.org/en/docs/DOM:window.stop
but this does not stop the current page from loading completely. Well,
it does in Firefox, but it doesn't in Safari, and since even one common
browser does what it shouldn't do, I didn't test further, because this
behaviour is too unsafe and therefore useless to me.
 
E

Evertjan.

Manfred Kooistra wrote on 04 jan 2007 in comp.lang.javascript:
RobG's guess that the code "should execute immediately" doesn't really
help me. I don't have the environment to test all prossible browsers
and configurations.
Click to expand...

Programming for "all prossible browsers" is an utopia.
What I need is to definitely exit the current page
as soon as the script is loaded.
Click to expand...

You should aim for multiple strategies, like:

<html>
<head>
<script type='text/javascript'>
window.location.href='file.php';
</script>
</head>
<noscript>
<body>
Only to be displayed if no is javascript available or switshed on.
</body>
</noscript>
Is there an "exit" or "die" function in JavaScript (as there is in
serverside scripting)?
Click to expand...

No.

Even serverside scripting has no "die" function,
an possibly empty html stream is always rendered.
 
M

Manfred Kooistra

Evertjan. said:
Even serverside scripting has no "die" function,
an possibly empty html stream is always rendered.
Click to expand...

Well, what I meant was that a redirect plus die in, say, PHP does not
give a flash of the non-executed rest of the script, but smoothly
redirects the user to a new page. A pure die of course still leaves the
user's browser with a http-response.

Anyway, thank you very much for the <noscript> tag idea. Great!

By the way, <noscript> may not contain a <body> tag, only block level
elements (for HTML Strict) or block level and inline elements (for HTML
Transitional). But since the whole content of my page is wrapped in a
<div> I can wrap this in the <noscript> tag and still validate as
Strict.
 
P

presidentjt

Let me explain: I want to test wether JavaScript is enabled or disabled
in the visitor's browser and serve two different pages accordingly.
Since I cannot do this serverside I need to test it by executing a
script: if it executes, JavaScript is enabled; if it does not execute,
JavaScript is disabled.
Click to expand...

this will work:

<html>
<head>
<title>htm</title>
<script type="text/javascript">
window.onload = function () {
window.location.href='page.htm?javascript=yes';
}
</script><noscript>
<meta http-equiv="refresh"
content="0;URL=page.htm?javascript=no';">
</noscript>
</head>

<body>
body content
</body>
</html>
 
D

Dr J R Stockton

In comp.lang.javascript message <[email protected]
glegroups.com>, Thu, 4 Jan 2007 01:43:18, Manfred Kooistra
Let me explain: I want to test wether JavaScript is enabled or disabled
in the visitor's browser and serve two different pages accordingly.
Since I cannot do this serverside I need to test it by executing a
script: if it executes, JavaScript is enabled; if it does not execute,
JavaScript is disabled.

So, if JavaScript is enabled, my script redirects to an alternative
page where the content offers JavaScript functionality, while, if
JavaScript is disabled, the current basic page (without JavaScript)
loads and is displayed.

I definitely do not want a flash of content, as this is ugly and
irritating to the visitor.
Click to expand...


Design the opening page (the one that javascript redirects away from) to
be short and simple (a good idea anyway) and try putting
document.body.style.display="none"
in the header script.

You may need to put a minimum timeout on the calling of the relocation,
so that the opening page has a chance to wipe itself.
 
M

Manfred Kooistra

<meta http-equiv="refresh"
content="0;URL=page.htm?javascript=no';">
</noscript>
Click to expand...

That would be a good idea: I could simply leave the document body
empty. But, as I wrote, I don't want to rely on meta refresh. IE6 has
an option in Custom Security settings to disable META refresh. This
disables redirects, though not refreshes of the same page. (Lynx, by
the way, does not meta redirect at all, but presents a link at the top
of the page.)

I think, the idea with the body content in <noscript> tags is the best
yet.

I would prefer serverside testing, but since this cannot be done ...
 
V

VK

If I have a document like this:
<html>
<head>
<script language=javascript>
window.location.href='file.php';
</script>
</head>
<body>
body content
</body>
</html>

will the JavaScript in the head execute before the body loads, or will
the visitor see a short flash of the content before the new page loads?
Click to expand...

In my strong opinion - you are free to disregard though - that is a
very wrong approach. Namely you are penalizing the absolute majority of
your users by forcing extra troubles on them. 99.9% of you visitors
will have JavaScript enabled; yet they will have a redirect in favor of
the remaining 0.1% of web-conceptualists and dorks (which is pretty
much the same, but to keep the stats transparent...)

That is like with a public restroom in some facility. You may and often
must to make it usable for an occasional visitor on wheelchair. At the
same time you must not make it available by default only for people on
wheelchair - but forcing everyone who can walk to make first a
"winner's circle" around your facility.

So solving the accessibility problem in the conventional way you have
the following options:

1) You are using JavaScript only to "beef up" your page: form helpers,
ads drivers, dynamic menus.
In this case just make sure that the basic navigation and form
submission is still possible even with script support disabled.

2) You are deploying an ajaxoid-driven web application or something
else where client-side scripting is a must.
In this case make sure to alert users with script support disabled and
give them an option either to hide the warning or to leave for some
"consolation page". Using <noscript> element and CSS you can make a
helper message of any complexity with as many options as you want.

3) You are deploying an ajaxoid-driven web application or something
else where client-side scripting is a must.
At the same time you - or your boss - just cannot sleep well thinking
of a few lost bucks and ready to spend as many bucks as needed to save
these few bucks.
In this case you are using a wrong tool for the job. Drop client-side
scripting all together and make a fully server-side driven application.
In this case making two identical solutions for client-side and
server-side is totally pointless: unless you are in urge to sign off
the rest of funding to prove to investors bigger numbers for the next
round - a dangerous doing btw.
 
M

Manfred Kooistra

VK said:
... you are penalizing the absolute majority of
your users by forcing extra troubles on them ...
Click to expand...

In a way you are right. That is why I am asking, if the script in the
head stops the page from loading. If it does, all that the "enabled
crowd" see is a splitsecond more of their empty browser background,
which they see anyway before a new page loads.

Recent statistics, by the way, show, that between 3 to 6% of all users
have JavaScript disabled. That is quite a lot. People are going on the
streets to get 2% higher wages!!! If we sell 6% more, we will be most
happy. And how do you know that not these careful few are the ones who
spend the most money on our website (which, for all that you know,
might be an insurance company and cater exactly to the anxious few)?

My first goal is to make my site accessible to all. No JavaScript, no
Flash, no you-name-it. Just simple HTML. But. There is an upload form.
Here users can send images. From my experience most (yes, most) users
don't really understand much about image resolution and file size and
send either tiny little mobile phone pictures or tiffs with 5 MB. Now,
if you upload three or ten images of several MB each, you will have to
wait quite a while. And if you upload your images through a basic HTML
form, nothing will happen during the minutes that it takes your images
to load to the server. This is frustrating, and I can understand all
the users that click around and break the transfer, because they think
something is wrong. So, what I want to display to them is an upload
status bar. And guess what: I need JavaScript to help me with that. All
solutions that I know of utilize JavaScript in some way, even if they
do the main work with Perl or whatever. Because you need JavaScript to
pop up or document.write the upload bar browserside.

So what I am doing is not a walk around the toilet, as you suggest, but
a sign telling the person who needs to pee, how long the toilet will be
occupied. Only those with JavaScript disabled will have to wait and see
or walk away a few seconds too early.

I would of course redirect those without JavaScript to the second page
and have the majority hit their content right away, but how?

How do I redirect - certainly, without failure, with no option to turn
this off, and in all browsers -, if JavaScript is disabled (and only
then)? All browsers regard the <noscript> tag.
 
V

VK

Manfred said:
Recent statistics, by the way, show, that between 3 to 6% of all users
have JavaScript disabled.
Click to expand...

That is a very hard to believe number. So up to 6% of Internet users do
not use portals, online email, online games, ticket booking systems, do
not buy music and video, do not use online banking - do nothing but
surfing by fall-back HTML leftovers where they can find them... By
average number rules there must be a certain percent of special users
of the needed kind, but 6% estimate is way too bad of thinking of the
Earth population.

The rule of thumb is: if your server stats shows anything above 0.1% of
script-disabled users then you've got either of two problems:
1) Your detecting mechanics gives wrong positives: investigate and
upgrade then.
2) Your site got a bad publicity so went into lesser-trusted / sniffing
sites list. Check it out immediately, that can be your competitor's
tricks.

The only exception from this rule is if you are contracted content
provider for some government establishment or a corporate unit. In this
case during the business hours you may have up to 100% of
script-disabled users, but this goes beyond the common accessibility
topics. Whatever you have to do with your content will be written in
the contract then.
My first goal is to make my site accessible to all.
Click to expand...

A good objective.
No JavaScript, no
Flash, no you-name-it. Just simple HTML. But. There is an upload form.
Here users can send images. From my experience most (yes, most) users
don't really understand much about image resolution and file size and
send either tiny little mobile phone pictures or tiffs with 5 MB.
Right.

Now,
if you upload three or ten images of several MB each, you will have to
wait quite a while. And if you upload your images through a basic HTML
form, nothing will happen during the minutes that it takes your images
to load to the server. This is frustrating, and I can understand all
the users that click around and break the transfer, because they think
something is wrong.
Click to expand...

Right, but there is a client-side scripting dependency in here? That
will be all the same for anyone. It is the age old "long form
submission" problem many times asked in this group.

For the most simple solution have an iframe banner atop of your form
and submit your form in there.
....
<iframe name="output" scr="formStatus.html" width="640"
height="60"></iframe>
<form method="POST" enctype="multipart/form-data" action="up.cgi"
target="output">
....
and on the server-side you have to make sure that _before anything
else_ your script has to check the submission for the minimum validity
(not an empty submission, file upload size doesn't exceed the quota)
and send back HTML page with the relevant message so to close HTTP
channel. Only after that do the rest: rename files, save them in
directories etc. For really long lasting server-side processes (5sec or
more) use the velocity.com techniques: before anything else replace the
current page with "Data is being processed" page instructed to upload
the URL with the session results in say 5 sec. Go to velocity.com and
search for some fly booking to see the full process.
Overall it is a complicated technical and usability task where purely
javascript-based cheap-chat tricks are not suitable - at least not for
an anyhow serious commercial solution.
So, what I want to display to them is an upload
status bar. And guess what: I need JavaScript to help me with that. All
solutions that I know of utilize JavaScript in some way, even if they
do the main work with Perl or whatever. Because you need JavaScript to
pop up or document.write the upload bar browserside.
Click to expand...

See the explanation above. Overall - as you may see by know - it is
rather pointless to talk about of an abstract "that if script
disabled on the page". It is much more productive to ask "how to do
this or that". This way the best way can be suggested with possible
fall-back alternatives.
So what I am doing is not a walk around the toilet, as you suggest, but
a sign telling the person who needs to pee, how long the toilet will be
occupied. Only those with JavaScript disabled will have to wait and see
or walk away a few seconds too early.
Click to expand...

You may consider it as coming back onto the rwar ground, but I don't
see why should you _enforce_ an alternative location for client-side
scripting disabled users. If scripting is an important part of
facilitating your interface usage, then explain it in brief words and
give them an option for an _explicit decision confirmed by a mouse
click or a keypress_ :
1) whether they want to use the fall-back variant on their own expences
2) or they want to go to alternative page.

Besides being as friendly as possible it eliminates the major part of
possible accessibility accusations.
I would of course redirect those without JavaScript to the second page
and have the majority hit their content right away, but how?
Click to expand...

Just one of options:

<html>
<head>
<title>Untitled Document</title>
<noscript><meta http-equiv="refresh"
content="0;http://www.google.com"></noscript>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
</head>
<body>
<h1>Welcome</h1>
</body>
</html>

P.S. But if we stay on the idea of a paranoidal user, then
meta-redirect can be manually disabled either, as well as any CSS.

I'm not an expert of sadomasochistic aspects of browsing, you have a
better chance at ciwas. Some people in there are spending day and
nights finding out what user could possibly change or disable - and in
what combination - to make her browsing experience the most miserable
and frustrating of possible.
:)
 
V

VK

Recent statistics, by the way, show, that between 3 to 6% of all users
Yes, as the number is probably closer to between 10 and 15% of users.
Click to expand...

90% to be exact. With 60% of all users surfing on Lynx and 30% on
Telnet. If we decided to play to "invent the crazy number" then I want
to participate either.

You never learn do you?
Click to expand...

It did not work for one of your test browsers?
 
M

Manfred Kooistra

The large majority of browser users never change the settings of their
browsers and never learn how to do it. That is why most Germans (that's
where I live) browse with their preferred language set to English (and
regularly get served English language versions of multilanguage
websites), because IE explorer is shipped with this setting even in
non-English-speaking countries. Most users do not know that this or
other options exist, just like they drive a car without understanding
about tire pressure, oil, coolant etc. They use what they get as it is,
and if it fails, they believe that the product is at fault.

So indeed the majority of browser users surf with JavaScript/JScript
enabled.

But. At the same time, data security is a major issue in Germany. This
not only pertains to web surfing, but to all other areas of everyday
life as well. I guess it is part of our historical heritage, with two
totalitarian systems in the recent past, that both abused knowledge of
their citizens' private thoughts and behaviours to better steer and
suppress them. There is no day that I do not read or hear about data
security issues at least three times in the newspaper, radio or tv. We
have ministries dedicated to protecting the privacy of the people, and
there is an ongoing debate about possible abuse of data by
irresponsible or over-zealous government agencies, corporations or
criminals. Computer security is a major part of this discussion, and
you can regularly read in the tips and tricks sections of magazines,
that you can or should disable cookies, JavaScript and disable whatnot.

So, there is a small percentage of users in Germany - and this
percentage has grown from about 1-3% in 2002 to the current 3-5% - that
disables everything they can disable. These users restrict their
enabled surfing to web sites that they have been told are safe
(because, of course, they do turn on JavaScript etc. if they want to),
and websites that work well in pure HTML (of which is the majority of
websites, by the way).

I see that we techies tend to disregard this behaviour as stupid. But
most people are not much interested in advanced technologies and how
they work. They like web sites with nifty blinking stuff, of course,
but most of all, they like things to be safe and "normal". Most web
sites are not designed for you and me, but for the secretary, the
insurance broker, the SF fan etc. - for the technically uneducated
user. And about 3-5% of them are irrationally afraid.

It is our job to deal with that. It is not their job to deal with what
we would like to design or program.

But I will think about what you all wrote and see if I can find a
better way. Thanks, VK, for the iframe idea.
 
R

Randy Webb

VK said the following on 1/7/2007 4:10 AM:
90% to be exact.
Click to expand...

No said:
With 60% of all users surfing on Lynx and 30% on Telnet.
If we decided to play to "invent the crazy number" then I want
to participate either.
Click to expand...

I said nothing about "invent the crazy number", I said the number of
3-6, in my personal experience, was too low. Nothing more and nothing less.
<snip noscript-meta-refresh trick>
Click to expand...

A "hack" would be a better word, not a trick.
It did not work for one of your test browsers?
Click to expand...

Once again, you failed to realize the implications or the flaws of your
approach.
 
V

VK

Manfred said:
The large majority of browser users never change the settings of their
browsers and never learn how to do it. That is why most Germans (that's
where I live) browse with their preferred language set to English (and
regularly get served English language versions of multilanguage
websites), because IE explorer is shipped with this setting even in
non-English-speaking countries.
Click to expand...

That's strange: normally localized versions of Windows have the
localization language set as the IE's default preferred. If it's still
set on en-US then it's a local distributor's failure to complain.
On my practice I often had to set default preferred on en-US for German
IE (for Americans working here) but I do not recall the opposite -
though I maybe just was lucky.
If you have enough of cases with German IE installations set to en-US
then it should be reported to IEAK sub-division:
Most users do not know that this or
other options exist, just like they drive a car without understanding
about tire pressure, oil, coolant etc. They use what they get as it is,
and if it fails, they believe that the product is at fault.

So indeed the majority of browser users surf with JavaScript/JScript
enabled.

But. At the same time, data security is a major issue in Germany.
This
not only pertains to web surfing, but to all other areas of everyday
life as well. I guess it is part of our historical heritage, with two
totalitarian systems in the recent past, that both abused knowledge of
their citizens' private thoughts and behaviours to better steer and
suppress them. There is no day that I do not read or hear about data
security issues at least three times in the newspaper, radio or tv. We
have ministries dedicated to protecting the privacy of the people, and
there is an ongoing debate about possible abuse of data by
irresponsible or over-zealous government agencies, corporations or
criminals.
Computer security is a major part of this discussion, and
you can regularly read in the tips and tricks sections of magazines,
that you can or should disable cookies, JavaScript and disable whatnot.
Click to expand...

Also German (European? France for sure) privacy politics is rather
different from the US. By making it more visual:
My SS# is my private data and no one should disclose it w/o my explicit
concern. Here America and Europe are going together.
At the same time I can use all available assets to publish my SS# in
all major US newspapers. I mean it is _my_ private data and as long as
it's not a state secret I am the only one to decide how private or
public to keep it.
In Germany someone else decides what is private, what I can tell to
anyone, what I'm not and what I can but only following the specified
procedure - so do not hurt myself. I consider it as another reflection
of more "paternalistic" relations between the government and citizens
in Europe. I hope I didn't hurt anyone and if I did then not too deeply
:) :-|
I knew of these differences back in 2001 and ever since the safe harbor
So, there is a small percentage of users in Germany - and this
percentage has grown from about 1-3% in 2002 to the current 3-5% - that
disables everything they can disable. These users restrict their
enabled surfing to web sites that they have been told are safe
(because, of course, they do turn on JavaScript etc. if they want to),
and websites that work well in pure HTML (of which is the majority of
websites, by the way).

I see that we techies tend to disregard this behaviour as stupid. But
most people are not much interested in advanced technologies and how
they work. They like web sites with nifty blinking stuff, of course,
but most of all, they like things to be safe and "normal". Most web
sites are not designed for you and me, but for the secretary, the
insurance broker, the SF fan etc. - for the technically uneducated
user. And about 3-5% of them are irrationally afraid.

It is our job to deal with that. It is not their job to deal with what
we would like to design or program.
Click to expand...

I didn't suggest to disregard script-disabled users, whatever their
number could be. I simply suggested to decide - on the design stage -
if your client-scripting beefs up the site or is it a vital part of a
usable interface.

For "beef up scripts" just make sure that the site is usable without
them.

For an interface where requests to server and DOM updates are fully
driven by javascript a "fall-back page" is a non-sense. Where do you
suppose to fall to? You have to decide:
1) either you provide some friendly warning using <noscript>
2) or you don't use javascript but implement a fully server-side driven
solution.
But I will think about what you all wrote and see if I can find a
better way. Thanks, VK, for the iframe idea.
Click to expand...

iframe, :hover / :active / :visited pseudo-elements, anchors, run-time
default form action override - there is a great number of different
approaches.

In your particular case though I see javascript usage as a facilitating
tool, so the page should be the same for everyone w/o any redirection.
You just need to check for a graceful fallback.
 

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

Similar Threads

Bash scripts for web apps 1
Help with Visual Lightbox: Scripts 2
What "might" I be doing wrong with this snippet? 6
Can't execute php to delete multiple rows in database 3
How do I hide the modal after 5 seconds? 4
About as basic "Newbie-Question" that you can get. 3
Script stops working when using variables to save time typing... 4
How does a HEAD pointer end up pointing to the first node in a linked list? 3

Members online

No members online now.
Total: 31 (members: 0, guests: 31)
Robots: 410

Forum statistics

Threads
473,755
Messages
2,569,536
Members
45,013
Latest member
KatriceSwa

Latest Threads

Top