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?
31  4916 
"Manfred Kooistra" <ma**************@gmx.dewrote in message
news:11**********************@6g2000cwy.googlegrou ps.com...
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?
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?
Manfred Kooistra wrote:
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,
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?
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.
--
Rob
McKirahan said the following on 1/3/2007 7:19 PM:
"Manfred Kooistra" <ma**************@gmx.dewrote in message
news:11**********************@6g2000cwy.googlegrou ps.com...
>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?
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>
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>
Same as above.
Or even this (which doesn't require that JavaScript be enabled):
But it does require that META Redirects be enabled in IE (where it can
be explicitly disabled).
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
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)?
Manfred Kooistra schrieb:
Is there an "exit" or "die" function in JavaScript (as there is in
serverside scripting)?
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.
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.
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.
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>
</html>
Is there an "exit" or "die" function in JavaScript (as there is in
serverside scripting)?
No.
Even serverside scripting has no "die" function,
an possibly empty html stream is always rendered.
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Evertjan. schrieb:
Even serverside scripting has no "die" function,
an possibly empty html stream is always rendered.
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 <noscripttag idea. Great!
By the way, <noscriptmay not contain a <bodytag, 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
<divI can wrap this in the <noscripttag and still validate as
Strict.
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.
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> pr*********@gmail.com schrieb:
<meta http-equiv="refresh"
content="0;URL=page.htm?javascript=no';">
</noscript>
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 <noscripttags is the best
yet.
I would prefer serverside testing, but since this cannot be done ...
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?
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 <noscriptelement 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. pr*********@gmail.com said the following on 1/4/2007 1:24 PM:
>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.
this will work:
No it won't.
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
VK schrieb:
... you are penalizing the absolute majority of
your users by forcing extra troubles on them ...
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 <noscripttag.
In comp.lang.javascript message <11**********************@11g2000cwr.goo
glegroups.com>, Thu, 4 Jan 2007 01:43:18, Manfred Kooistra
<ma**************@gmx.deposted:
>
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.
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.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Delphi 3? Turnpike 6.05
<URL:http://www.merlyn.demon.co.uk/TP/BP/Delphi/&c., FAQqy topics & links;
<URL:http://www.bancoems.com/CompLangPascalDelphiMisc-MiniFAQ.htmclpdmFAQ;
<URL:http://www.borland.com/newsgroups/guide.htmlnews:borland.* Guidelines
Manfred Kooistra wrote:
Recent statistics, by the way, show, that between 3 to 6% of all users
have JavaScript disabled.
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.
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.
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.
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.
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?
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.
:-)
VK said the following on 1/6/2007 4:32 PM:
Manfred Kooistra wrote:
>Recent statistics, by the way, show, that between 3 to 6% of all users
have JavaScript disabled.
That is a very hard to believe number.
Yes, as the number is probably closer to between 10 and 15% of users.
<snip>
Just one of options:
You never learn do you?
<snip>
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Recent statistics, by the way, show, that between 3 to 6% of all users
have JavaScript disabled.
That is a very hard to believe number.
Yes, as the number is probably closer to between 10 and 15% of users.
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.
Just one of options:
<snip noscript-meta-refresh trick>
You never learn do you?
It did not work for one of your test browsers?
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.
VK said the following on 1/7/2007 4:10 AM:
>>>Recent statistics, by the way, show, that between 3 to 6% of all users
have JavaScript disabled.
That is a very hard to believe number.
Yes, as the number is probably closer to between 10 and 15% of users.
90% to be exact.
No, it is exactly and precisely ~92.2341123% of users. <eyeroll>
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.
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.
>>Just one of options:
<snip noscript-meta-refresh trick>
A "hack" would be a better word, not a trick.
>You never learn do you?
It did not work for one of your test browsers?
Once again, you failed to realize the implications or the flaws of your
approach.
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Manfred Kooistra wrote:
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.
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:
<http://www.microsoft.com/technet/prodtechnol/ie/ieak/de/default.mspx>
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.
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
program <http://www.export.gov/safeharbor/sh_overview.htmlis my
regular suggestion to anyone expanding to Europe.
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.
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.
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.
Randy Webb wrote:
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.
OK, let's stop then on that I'm sitting on the other side of the pond
(on the other coast ?) where this problem is not presented bur remains
a mind game.
<snip noscript-meta-refresh trick>
A "hack" would be a better word, not a trick.
You never learn do you?
It did not work for one of your test browsers?
Once again, you failed to realize the implications or the flaws of your
approach.
meta-refresh can be disabled as well - but I said it right away.
Provide an extra <noscriptwith instructions and a link. What else?
Oh, yeh... There is a well-known rather buggy validator, still in beta
but used by many. According to some last century DTD it is a terrible
crime what I suggested. Well, that is a personal choice I guess
everyone has to make: you want a green banner from that validator or
you want as much money as possible from your visitors. I don't dare to
push with any decision.
Any _technical_ implications?
VK said the following on 1/7/2007 11:49 AM:
Randy Webb wrote:
>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.
OK, let's stop then on that I'm sitting on the other side of the pond
(on the other coast ?) where this problem is not presented bur remains
a mind game.
JS enabled is a mind game no matter where you are.
>><snip noscript-meta-refresh trick>
A "hack" would be a better word, not a trick.
>>>You never learn do you?
It did not work for one of your test browsers?
Once again, you failed to realize the implications or the flaws of your
approach.
meta-refresh can be disabled as well - but I said it right away.
Yes, but that was not the problem.
Provide an extra <noscriptwith instructions and a link. What else?
In a simple scenario like you posted, it "works". But the simple idea of
putting the non-JS version in a noscript element is what is wrong. If a
script error occurs anywhere in the page then the user with JS enabled
is left with nothing.
Oh, yeh... There is a well-known rather buggy validator, still in beta
but used by many.
Who said anything about a validator? My opinion of the validator has
been stated before and it ranks right up there with my opinion of
semicolons at the end of every statement. It's a decent tool but it is
not the end all to all ends.
According to some last century DTD it is a terrible crime what I suggested.
How you got from a noscript element not satisfying the needs to some DTD
is beyond me.
Well, that is a personal choice I guess everyone has to make: you want a
green banner from that validator or you want as much money as possible
from your visitors. I don't dare to push with any decision.
Who said anything about a validator?
Any _technical_ implications?
<script type="text/javascript" src="external.js">
//third party script with an error in it
//Think library or Google AdSense or tracking
//code that is third party that you have no
//control over.
</script>
<script type="text/javascript">
//document creating script here
</script>
<noscript>
This page......
</noscript>
Your move!
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Randy Webb wrote:
Any _technical_ implications?
<script type="text/javascript" src="external.js">
//third party script with an error in it
//Think library or Google AdSense or tracking
//code that is third party that you have no
//control over.
</script>
<script type="text/javascript">
//document creating script here
</script>
<noscript>
This page......
</noscript>
Uhm... I'm missing to see a connection between disabled scripting and
run-time error handling. The first is out of developer's control, one
can only to check for a suitable fall-back including by not limited by
options provided by <noscriptelement.
Run-time errors handling is under your full control: it is yours to
decide what to do. It is also up to you to check all 3rd party
libraries provide errors handling and do not interfer with your own
error handling. If negative then request to update the 3rd party
library or - if it's not an option - do not use such library.
Really, it's like asking:
- My script on page load attempts to create new XSLTProcessor object
without checking if the relevant constructor is available. What does
<noscripthave to propose on this subject?
- Well, nothing, I guess...
VK said the following on 1/8/2007 10:12 AM:
Randy Webb wrote:
>>Any _technical_ implications?
<script type="text/javascript" src="external.js">
//third party script with an error in it
//Think library or Google AdSense or tracking
//code that is third party that you have no
//control over.
</script>
<script type="text/javascript">
//document creating script here
</script>
<noscript>
This page......
</noscript>
Uhm... I'm missing to see a connection between disabled scripting and
run-time error handling. The first is out of developer's control, one
can only to check for a suitable fall-back including by not limited by
options provided by <noscriptelement.
How many times does something have to be explained to you before it
_finally_ sinks in? The NOSCRIPT element and the problems with it have
been explained to you many many times yet you still don't understand it.
I will try, one more futile time, to explain it to you. There are three
scenarios that can happen:
1) Script is disabled.
2) Script is enabled.
3) Script is enabled with an error in a script block.
Your example only covers two of those scenarios. You can search the
archives for the many many other times that it has been explained and
maybe you can endeavor to understand it, I am not going to type it all
out again.
Needless to say but all three of those possibilities can be dealt with
and the page will *not* include a noscript element.
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Randy Webb wrote:
How many times does something have to be explained to you before it
_finally_ sinks in? The NOSCRIPT element and the problems with it have
been explained to you many many times yet you still don't understand it.
You may do it 100 more times and still there is not a slightest
relation between two absolutely different problems:
1) scripting is disabled on the current user agent.
2) scripting is enabled by the script on the page resulted into syntax
or runtime error.
For the first problem you're checking you page usability with script
disabled. Or - providing text and links using <noscriptblocks.
For the second problem you are testing your program to make sure it
works. You also deside what to do if the current configuration doesn't
provide vital features necessary for the script execution.
I cannot understant what magical link do you see between these two
topics and why do they have to be put together.
In the following code:
<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
</head>
<body>
<script type="text/javascript">
// syntax error;
!@#$%^;
</script>
<noscript>
<p>Script is disabled</p>
</noscript>
</body>
</html>
"Script is disabled" message is not displayed. <noscriptdoes it job
with script error or without it. So leave it alone now.
If you want to discuss "how to detect features at runtime and avoid or
catch runtime errors" then it's all different topic. Gladly let's talk
about it: just stop making mishmash or script errors and disabled
script.
If you want to discuss "should one check that her script runs at least
once before publishing the page" then there is nothing to discuss
here... I hope... sure you do.
VK said the following on 1/8/2007 12:47 PM:
Randy Webb wrote:
>How many times does something have to be explained to you before it
_finally_ sinks in? The NOSCRIPT element and the problems with it have
been explained to you many many times yet you still don't understand it.
You may do it 100 more times and still there is not a slightest
relation between two absolutely different problems:
I could explain it to you 1000 times and you still wouldn't understand
the drawbacks/flaws in the noscript element. As I said, you can search
the archives and find the flaws. It has been explained many times and I
showed you an example where it doesn't do what is desired.
1) scripting is disabled on the current user agent.
2) scripting is enabled by the script on the page resulted into syntax
or runtime error.
For the first problem you're checking you page usability with script
disabled. Or - providing text and links using <noscriptblocks.
No, you don't use noscript for that. You use a normal block element and
replace the contents using script. If there is a script error then the
script enabled user still gets the links and any explanations about
script. The noscript element doesn't cover that scenario and it can't.
For the second problem you are testing your program to make sure it
works. You also deside what to do if the current configuration doesn't
provide vital features necessary for the script execution.
And if the UA doesn't provide the feature then what? The script enabled
user gets nothing. That isn't very user friendly nor accessible.
I cannot understant what magical link do you see between these two
topics and why do they have to be put together.
In the following code:
<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
</head>
<body>
<script type="text/javascript">
// syntax error;
!@#$%^;
</script>
<noscript>
<p>Script is disabled</p>
</noscript>
</body>
</html>
"Script is disabled" message is not displayed. <noscriptdoes it job
with script error or without it. So leave it alone now.
And the user is left with nothing. That is the part you don't understand
and refuse to try to understand. There are better alternatives to
noscript and they work better - hands down - than the noscript element
*ever* will.
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Randy Webb wrote:
I could explain it to you 1000 times and you still wouldn't understand
the drawbacks/flaws in the noscript element. As I said, you can search
the archives and find the flaws.
I don't need to search archives: I am myself an archive of <noscript>
usage in all forms and fashions.
The only possible flaw with <noscriptis well possibly gone years ago
but still who wants to check it on her own site? I'm talking about
badly written indexing engine which can index <noscriptcontent and
even take the first paragraph out of it for the search result sample -
if <noscriptis the first element of body. This way <noscriptshould
be placed at the bottom of body content but displayed at the top of the
page using CSS.
No, you don't use noscript for that. You use a normal block element and
replace the contents using script.If there is a script error then the
script enabled user still gets the links and any explanations about
script.
Eh? Looks like your own invention - this is why you are so insistent on
it. Seems highly unreliable to me, but can I see a working demo?
The noscript element doesn't cover that scenario and it can't.
And if the UA doesn't provide the feature then what?
What a baby question, really. Whatever you decided to do at the design
time. Show alert and exit, show message DIV and exit, prompt for
redirection to an alt page, silently die as if with script disabled (if
the page is ready for no-script usage).
That's again: you're mixing honey and salt and telling it's the way to
eat it.
The script enabled user gets nothing.
That isn't very user friendly nor accessible.
If you did not provide any feature check/error treatment mechanics in
your script then user gets nothing - besides status bar sign on IE and
error meassage on JS Console on other UA.
But feature check/error treatment mechanics _has_ to be in your script
if it is properly written, so no problem to show any message in any
format at runtime. Really, what's the problem?
VK wrote:
That's again: you're mixing honey and salt and telling it's the way to
eat it.
Like in the "Preloader..." thread.
For the users with script disabilities that will be "Loading..."
message forever. Highly friendly ;-)
Again step by step:
1) If user has a script disability, it cannot get script errors by
definition: because no script will be executed. So concentrate on what
you have to say or show (if anything) to this user.
2) If you have a runtime error, it means by definition that script is
enabled. How will you treat an error situation or missing vital feature
(say XSLT tools) has to be thought throughout at the time you were
making your program. If you are using 3rd party libraries, their
behavior has to be tested at the design time as well.
Very different situations requiring different solutions.
VK wrote:
Eh? Looks like your own invention - this is why you are so insistent on
it. Seems highly unreliable to me, ...
bias. need some sleep.
And if the UA doesn't provide the feature then what?
Whatever you decided to do at the design
time. Show alert and exit, show message DIV and exit, prompt for
redirection to an alt page, silently die as if with script disabled (if
the page is ready for no-script usage).
<snip>
staying on all the rest.
VK said the following on 1/8/2007 4:24 PM:
Randy Webb wrote:
>I could explain it to you 1000 times and you still wouldn't understand
the drawbacks/flaws in the noscript element. As I said, you can search
the archives and find the flaws.
I don't need to search archives: I am myself an archive of <noscript>
usage in all forms and fashions.
Are you actually as full of yourself in RL as you are here? I find it
difficult to believe that anybody that possesses the level of
intelligence you display here can make it through normal day to day life.
The only possible flaw with <noscriptis well possibly gone years ago
but still who wants to check it on her own site?
The is not the only flaw with it. You just fail to realize the real flaw
in using the noscript element.
>No, you don't use noscript for that. You use a normal block element and
replace the contents using script.If there is a script error then the
script enabled user still gets the links and any explanations about
script.
Eh? Looks like your own invention - this is why you are so insistent on
it. Seems highly unreliable to me, but can I see a working demo?
I showed you one. There are also several of them in the archives. I
would tell you to find it but you are already a - self proclaimed -
archive on it so I won't waste my time.
The noscript element doesn't cover that scenario and it can't.
You finally figured it out! Why use a half witted solution when a better
one exists?
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
The best entertainment in this newsgroup is, and will always be, the
Randy Webb vs. VK discussions.
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Display Name |
last post by:
the customer I'm developing a site for uses a canned form-parsing page that
allows her to have an email subscription opt-in page add emails to a list
she can manage using a link that you point your...
|
by: Ed Brandmark |
last post by:
I have a tag of the form
<SCRIPT LANGUAGE="JavaScript1.1" SRC="foo.js".....
and was wondering if this delays the loading of my page until that
file foo.js downloads.
It seems that if I place...
|
by: Unregistered |
last post by:
Hello!
I came across two different scripts that I wanted to combine, and I thought I wa
successful until I discovered a minor glitch.
What was happening was that the page that was linked to...
|
by: JR |
last post by:
Hi. I have a CGI script that will need to call itself an unknown
number of times, to add rows, run queries, etc. At the bottom of the
output that is produced by the script, there are four...
|
by: Jake Lewis |
last post by:
I have an HTML page that loads fine including the .js file
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
<title>Untitled Document</title>
<script...
|
by: Tom Braun |
last post by:
Hello!
My first post here...
I need to monitor if someone clicked on some (any) link in a subframe.
Due to certain restrictions, the only place I can put some JavaScript
is in the main...
|
by: Bob |
last post by:
I have created some WSH scripts on my Webserver that are executed by
the Windows Task Scheduler. I want to be able to execute some of these
scripts using a web interface and don't want to duplicate...
|
by: petermichaux |
last post by:
Hi,
My AJAX response is a bit of HTML that I insert into the DOM. I extract
the contents of the script elements in the response into an array
called aScripts. I then want to append these to an...
|
by: yawnmoth |
last post by:
I'm trying to write a script whereby the body background is changed to
back (from white) when the mouse button is held down and kept held
down. When you lift it up, I'd like it to change back to...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The...
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated ...
| |
