When do scripts in document head execute?

[VK]

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.

A "hack" would be a better word, not a trick.


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 <noscript> with 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?

 

[Randy Webb]

VK said the following on 1/7/2007 11:49 AM:

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.

meta-refresh can be disabled as well - but I said it right away.

Yes, but that was not the problem.

Provide an extra <noscript> with 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!

 

[VK]

<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 <noscript> element.

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
<noscript> have to propose on this subject?

- Well, nothing, I guess...

 

[Randy Webb]

VK said the following on 1/8/2007 10:12 AM:

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 <noscript> element.

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.

 

[VK]

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 <noscript> blocks.

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. <noscript> does 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.

 

[Randy Webb]

VK said the following on 1/8/2007 12:47 PM:

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 <noscript> blocks.

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. <noscript> does 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.

 

[VK]

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 <noscript> is 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 <noscript> content and
even take the first paragraph out of it for the search result sample -
if <noscript> is the first element of body. This way <noscript> should
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]

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]

Eh? Looks like your own invention - this is why you are so insistent on
it. Seems highly unreliable to me, ...

bias. need some sleep.

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.

 

[Randy Webb]

VK said the following on 1/8/2007 4:24 PM:

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 <noscript> is 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.

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?

 

[Paul]

The best entertainment in this newsgroup is, and will always be, the
Randy Webb vs. VK discussions.

 

[Randy Webb]

Paul said the following on 1/10/2007 3:50 PM:

The best entertainment in this newsgroup is, and will always be, the
Randy Webb vs. VK discussions.

Glad I could be your entertainment for a few days.