object expected error

eruanion

Hi, I've been working on this for a while now and I can't seem to find
out what is wrong with my code. I have 2 files one c3common.js which
only contains javascript functions for my main html page and my main
html page which is test.html. They are of course part of a much bigger
system of files but i have tracked down the problem to that reduced
part of the code. The page loads perfectly fine however when i click
search i get the error line:37 object expected, which is the line of
the <form name=...... onSubmit="return validate(this);"> The code
basically just takes the data entered in name, email and phone number
and validates them with premade functions. now i know theres nothing
wrong with the functions in c3common.js because when i cut and paste
them into the html page in the script part everything starts working
perfectly but as soon as i move them into another .js file and link the
html page with the scr="c3common.js" piece of code i get the error. Oh
and before you ask the files are in the same directory so thats not the
problem. Thanks a lot for your time guys.

here it goes:

test.html =

<html>
<head>
<title>ShowEmployees (using JSTL)</title>

<script src="c3common.js" type="text/javascript"
language="JavaScript">

function validate(form)
{

window.alert("CHECK!"); //this never even gets shown at all

var check =1;

if(CheckName(form.name.value) == false)
{
window.alert("wrong name");
check =0;
}
if(CheckEmail(form.email.value) == false)
{
window.alert("wrong email");
check =0;
}
if(CheckPhoneNumber(form.telephone.value) == false)
{
window.alert("wrong telephone");
check =0;
}

return check;
}
</script>
</head>

<body>

<form name="search" method="POST" onsubmit="return
validate(this);">
<h1>Searching Employees Database</h1>

<table>
<tr>
<td>Name</td> <td><input type="text" name="name" value=""/> </td>
</tr>
<tr>
<td>E-mail Address</td> <td><input type="text" name="email"
value=""/> </td>
</tr>
<tr>
<td>Phone number</td> <td><input type="text" name="telephone"
value=""/> </td>
</tr>
<tr>
<td><input type="hidden" name="action" value="showEmployees"/>
</td>
<td><input type="hidden" name="page" value="0" /> </td>
</tr>
<tr>
<td><input type="submit" name="submit" value="Search"/> </td>
<td><input type="reset" value="Resets all fields"/> </td>
</tr>
</table>
</form>
</body>
</html>

Feb 27 '06 #1

Subscribe Post Reply

13357

eruan...@hotmail.com wrote:

<html>
<head>
<title>ShowEmployees (using JSTL)</title>

<script src="c3common.js" type="text/javascript"
language="JavaScript">

function validate(form)

You cannot use one <script> tag for both .js file and inline code:-
inline code is being ignored in this case.

Change to:

<script src="c3common.js" type="text/javascript"></script>
<script type="text/javascript">
// inline code
</script>

As I see this error over and over in different places, I presume that
some "reputable" source claims that it's possible. If it's a wiki I
would appreciate to be pointed out so I could correct the article.

P.S. It is generally a bad idea to name you form field "name" - it may
lead to some funny addressing issues.
"customer", "user", "requester" etc. are much better.

Feb 27 '06 #2

eruanion

ohh thank you soo much, for some reason i has tried that before but
then i had made some changes to the code that might have messed it up,
works perfectly now thx.

Feb 27 '06 #3

Richard Cornford

VK wrote:

eruan...@hotmail.com wrote:
<html>
<head>
<title>ShowEmployees (using JSTL)</title>

<script src="c3common.js" type="text/javascript"
language="JavaScript">

function validate(form)
You cannot use one <script> tag for both .js file and
inline code:-

You cannot use one SCRIPT _tag_ for anything as HTML requires two script
tags to define one SCRIPT element (opening and closing tags are not
optional).

But you can use one SCRIPT element to import a file and simultaneously
define script within that element. It isn't a good idea to do so but it
is a reasonably commonly implemented facility; see the FAQ.
inline code is being ignored in this case.
That would depend upon the browser and factors beyond your current
understanding.
Change to:

<script src="c3common.js" type="text/javascript"></script>
<script type="text/javascript">
// inline code
</script>
That is 4 _tags_ defining two _elements_. Acquiring a basic
understanding of HTML would be a good idea prior to attempting to give
advice on the subject. The distinction between an HTML tag and an
element being pretty basic.
As I see this error over and over in different places, I
presume that some "reputable" source claims that it's possible. <snip>

You see something you don't understand and assume that it is an error,
but the one does not follow from the other, especially as you don't
actually understand the code you write yourself (even if you are not
necessarily aware of that yourself).
P.S. It is generally a bad idea to name you form field "name"
- it may lead to some funny addressing issues.
"customer", "user", "requester" etc. are much better.

Name or NAME would do just as well, as javascript is case sensitive.

Richard.

Mar 1 '06 #4

Thomas 'PointedEars' Lahn

Richard Cornford wrote:

VK wrote:
eruan...@hotmail.com wrote:
<html>
<head>
<title>ShowEmployees (using JSTL)</title>

<script src="c3common.js" type="text/javascript"
language="JavaScript">

function validate(form)
You cannot use one <script> tag for both .js file and
inline code:-

You cannot use one SCRIPT _tag_ for anything as HTML requires two script
tags to define one SCRIPT element (opening and closing tags are not
optional).

True.
But you can use one SCRIPT element to import a file and simultaneously
define script within that element.
No, you cannot. It is specified and implemented that

,-[HTML 4.01, 18.2.1 The SCRIPT element]
|
| [...] If the `src' has a URI value, user agents must ignore
| the element's contents and retrieve the script via the URI.

See below.

(There is also a common misconception among some people here regarding the
`charset' attribute [but the FAQ is clear and correct about it, the misuse
of the "tag" term aside] that is addressed by the next sentence of the
spec:

"Note that the `charset' attribute refers to the character encoding of the
script designated by the `src' attribute; it does not concern the content
of the SCRIPT element.")
It isn't a good idea to do so
True.
but it is a reasonably commonly implemented facility;
It is not in Netscape 4.8, Mozilla 1.7.12, Firefox 1.5.0.1, Opera 8.52, and
KHTML 3.5.1:

<URL:http://pointedears.de/scripts/test/include>

Netscape 4.8 even navigates to the Error 404 document if a script resource
is specified that does not exist. (Interestingly, KJS 3.5.1 does not allow
for augmentation of the Object constructor.)
see the FAQ.

The FAQ has to be corrected in that regard.
PointedEars

Mar 1 '06 #5

Thomas 'PointedEars' Lahn

Thomas 'PointedEars' Lahn wrote:

<URL:http://pointedears.de/scripts/test/include>

[...] (Interestingly, KJS 3.5.1 does not allow for augmentation of the
Object constructor.)

Ignore that, it does. It is just that the remote version of object.js still
used FunctionExpressions in Object literals which are not supported by KJS
as yet. Therefore the included script could not be compiled, and the
Object constructor was not augmented. If you use only references to those
Function objects instead, everything is fine.
PointedEars

Mar 12 '06 #6

Thomas 'PointedEars' Lahn

Thomas 'Ingrid' Lahn wrote:

Thomas 'PointedEars' Lahn wrote:
<URL:http://pointedears.de/scripts/test/include>

[...] (Interestingly, KJS 3.5.1 does not allow for augmentation of the
Object constructor.)

Ignore that, it does. It is just that the remote version of object.js
still used FunctionExpressions in Object literals which are not supported
by KJS as yet. Therefore the included script could not be compiled, and
the Object constructor was not augmented. If you use only references to
those Function objects instead, everything is fine.

It gets even more strange: the above statement is not generally true.
I have reduced the problem to the following:

var x = {
y: function z() {}
};

and

// or: var x = function() {};
// that does not make a difference
function x() {};

// The following line triggers a "read error" (message; if you have
// enabled debugging)
x({
y: function z() {}
});

If you omit the `z', thereby making the function anonymous, the error
goes away. Can anyone with a KHTML-based UA confirm or deny that?
Can anyone explain that?
PointedEars

Mar 12 '06 #7

Thomas 'PointedEars' Lahn

Thomas 'PointedEars' Lahn wrote:

I have reduced the problem to the following:

var x = {
y: function z() {}
};

and

// or: var x = function() {};
// that does not make a difference
function x() {};

// The following line triggers a "read error" (message; if you have
// enabled debugging)
x({
y: function z() {}
});

If you omit the `z', thereby making the function anonymous, the error
goes away. Can anyone with a KHTML-based UA confirm or deny that?
Can anyone explain that?

I have reported this now as
<URL:https://bugs.kde.org/show_bug.cgi?id=123529>
PointedEars

Mar 13 '06 #8

Ben C

On 2006-03-13, Thomas 'PointedEars' Lahn <Po*********@web.de> wrote:

Thomas 'PointedEars' Lahn wrote:

If you omit the `z', thereby making the function anonymous, the error
goes away. Can anyone with a KHTML-based UA confirm or deny that?
Can anyone explain that?

I tried this in Konqueror, and got a parse error. If I left out the z it
worked. It worked on firefox both ways.

var x = {
y: function z() { alert("hello"); }
};
x.y();

It is definitely a bug because the grammar defines a FunctionExpression
as:

function Identifier<opt> (FormalParameterList<opt>) {FunctionBody}

So you should be allowed to have that Identifier there if you want one,
and you might need it if you wanted to make the function recursive.

Mar 13 '06 #9

Richard Cornford wrote:

But you can use one SCRIPT element to import a file and simultaneously
define script within that element. It isn't a good idea to do so but it
is a reasonably commonly implemented facility; see the FAQ.

What FAQ? I hope it's not the official group FAQ at
<http://www.jibbering.com/faq>? I looked at and I did not see anything
similar - but I might missed it. If so, it should be corrected
immediately as it's a gross error.

<script type="text/javascript" src="outer.js">
inner:
</script>

In this case inner block will be ignored and only outer file executed.
This is really a basic - it was this way ever since src attribute was
introduced. I am not aware of any browsers having different behavior.

Just for hell of it I tested the sample below on NN 4.5 (for my memory
check), IE.6.0, FF 1.5 and Opera 8.5:

<html>
<head>
<title>Script in Script doesn't work</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<script type="text/javascript" src="outer.js">
window.alert('Hi from inner!');
</script>
</head>

<body>

</body>
</html>

// where outer.js contains:
window.alert('Hi from outer!');

Mar 14 '06 #10

Randy Webb

VK said the following on 3/14/2006 3:56 AM:

Richard Cornford wrote:
But you can use one SCRIPT element to import a file and simultaneously
define script within that element. It isn't a good idea to do so but it
is a reasonably commonly implemented facility; see the FAQ.
What FAQ? I hope it's not the official group FAQ at
<http://www.jibbering.com/faq>? I looked at and I did not see anything
similar - but I might missed it. If so, it should be corrected
immediately as it's a gross error.

IIRC, it is in the notes section. It was an attempted hack to try to
determine if an external file had been loaded or not.
<script type="text/javascript" src="outer.js">
inner:
</script>

Mar 14 '06 #11

Randy Webb wrote:

VK said the following on 3/14/2006 3:56 AM:
Richard Cornford wrote:
But you can use one SCRIPT element to import a file and simultaneously
define script within that element. It isn't a good idea to do so but it
is a reasonably commonly implemented facility; see the FAQ.

What FAQ? I hope it's not the official group FAQ at
<http://www.jibbering.com/faq>? I looked at and I did not see anything
similar - but I might missed it. If so, it should be corrected
immediately as it's a gross error.

IIRC, it is in the notes section. It was an attempted hack to try to
determine if an external file had been loaded or not.
<script type="text/javascript" src="outer.js">
inner:
</script>

<script type="text/javascript" src="fileThatDidntLoad.js">
//code here
</script>

I think you have to look back at some of the older IE and NS browsers
(NS6/7) to find browsers that will execute the code block. IE6 throws an
Invalid Character error on a src file that doesn't exist.

There is nothing to look at: it is exactly as I said and always was
this way.
But I guess I can guess :-) how this error appeared:- when Netscape
introduced src attribute and external .js file concept, they also
provided a fallback option for older Netscape versions: "inner script
statements are ignored if src attribute is set and recognized". So
looking at legacy scripts (must be really ancient though) one can see
something like:

<script language="JavaScript" src="myScript.js">
window.alert("External scripts are not supported.");
</script>

If the inner block is not so obvious as in the sample above, one may
decide that both inner and outer scripts are allowed in one tag set.
But in the reality the inner block is a *fallback code* in case if src
attribute is not supported.

As there are not any modern browsers w/o script src support, this
fallback option is currently useless (though still supported for legacy
reasons).

It is important to repeat that "inner script statements are ignored if
src attribute is *set and recognized*". It means that the src attribute
support by itself tourns inner block parsing off - so it cannot be used
for fallback if external file is not available. If in the posted sample
you change to:

<script type="text/javascript" src="non_existing_file.js">
inner:
</script>

and the inner block still will be ignored. This behavior is consistent
since NN 3.x

Mar 14 '06 #12

VK wrote:

There is nothing to look at: it is exactly as I said and always was
this way.
But I guess I can guess :-) how this error appeared:- when Netscape
introduced src attribute and external .js file concept, they also
provided a fallback option for older Netscape versions: "inner script
statements are ignored if src attribute is set and recognized". So
looking at legacy scripts (must be really ancient though) one can see
something like:

<script language="JavaScript" src="myScript.js">
window.alert("External scripts are not supported.");
</script>

If the inner block is not so obvious as in the sample above, one may
decide that both inner and outer scripts are allowed in one tag set.
But in the reality the inner block is a *fallback code* in case if src
attribute is not supported.

As there are not any modern browsers w/o script src support, this
fallback option is currently useless (though still supported for legacy
reasons).

It is important to repeat that "inner script statements are ignored if
src attribute is *set and recognized*". It means that the src attribute
support by itself tourns inner block parsing off - so it cannot be used
for fallback if external file is not available. If in the posted sample
you change to:

<script type="text/javascript" src="non_existing_file.js">
inner:
</script>

and the inner block still will be ignored. This behavior is consistent
since NN 3.x

I guess I found the offending line (thanks to Randy Webb for his hint):
<http://jibbering.com/faq/faq_notes/script_tags.html#hsMix>

In the name of Tim and Brendan :-), anyone - please take it out or
change as described in this thread - *right now*!

Mar 14 '06 #13

Richard Cornford

Randy Webb wrote:
<snip>

<script type="text/javascript" src="outer.js">
inner:
</script>
<script type="text/javascript" src="fileThatDidntLoad.js">
//code here
</script>

I think you have to look back at some of the older IE and NS browsers
(NS6/7) to find browsers that will execute the code block. IE6 throws an
Invalid Character error on a src file that doesn't exist.

Unfortunately if IE throws an invalid character error then you have not
tested the phenomenon as that is the symptom of the response form the
SRC request being treated as if it was javascript source. As browsers
treat whatever (non-HTTP error) response they get from the server when
they attempt to load a SRC as javascript source text, regardless of
headers, you can only test this using an HTTP server that is properly
set up to respond to a request for a missing resource with a
well-formed 404 HTTP error.

A server that just sends HTML error pages (as opposed to HTML content
for a 404 error) will give the browser the impression that the remote
file does exist. The same goes for local files system testing with IE
as the error page that would be displayed if you entered a file
protocol URL for a non-existing file into the address bar is the same
page that gets sent to the javascript interpreter when a non-existing
file is referenced with a SRC.
And yes, it should be removed.

Probably not, although it may benefit from more emphasis on the
non-universal browser support instead of just the issues with proper
HTTP 404 errors and the fact that the entire technique is unnecessary
in practice.

Richard.

Mar 14 '06 #14

Richard Cornford wrote:

Randy Webb wrote:
<snip>
<script type="text/javascript" src="outer.js">
inner:
</script>

<script type="text/javascript" src="fileThatDidntLoad.js">
//code here
</script>

I think you have to look back at some of the older IE and NS browsers
(NS6/7) to find browsers that will execute the code block. IE6 throws an
Invalid Character error on a src file that doesn't exist.

Unfortunately if IE throws an invalid character error then you have not
tested the phenomenon as that is the symptom of the response form the
SRC request being treated as if it was javascript source. As browsers
treat whatever (non-HTTP error) response they get from the server when
they attempt to load a SRC as javascript source text, regardless of
headers, you can only test this using an HTTP server that is properly
set up to respond to a request for a missing resource with a
well-formed 404 HTTP error.

I am sorry but Randy's case has to contain some extra error in it -
this is why it caused an error in IE.

This sample works as expected (inner block is silently ignored):

<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<script language="JavaScript" src="fileThatDidntLoad.js">
alert("Hi from inner!");
</script>
</head>

<body>

</body>
</html>

I want to clarify once again: this is *missing feature fallback*, not
resource availability fallback.
If current UA understands and supports src attribute for script tag and
if this attribute is set to anything except empty string:- in this case
inner block is not parsed nor executed. It has absolutely nothing to do
with server response (200, 404, XYZ). For resource availability one
need to use onError handler (unfortunately supported by IE only), or
periodically check typeof of some variable in the *outer script*:

if ('undefined' == typeof someVar) {
setTimeout(// for another check
}

Mar 14 '06 #15

Richard Cornford

VK wrote:
<snip>

I am sorry but Randy's case has to contain some extra error in it -
this is why it caused an error in IE.

<snip>

And where would those errors be? In the external file that did not
exits or in the content of the SCRIPT element that was ignored? It is
reasoning like this that makes your opinion on anything worthless.

Richard.

Mar 14 '06 #16

Thomas 'PointedEars' Lahn wrote:

It gets even more strange: the above statement is not generally true.
I have reduced the problem to the following:

var x = {
y: function z() {}
};

and

// or: var x = function() {};
// that does not make a difference
function x() {};

// The following line triggers a "read error" (message; if you have
// enabled debugging)
x({
y: function z() {}
});

You would be even more amazed if you try your sample on any IE or an
old Netscape. If I'm reading your intentions right the result would be
far from expected ones:

<html>
<head>
<title>Test</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<script>
var x = {
y: function z() { alert("hello"); }
};
alert(z); // displays z function body
</script>
</head>
<body>
</body>
</html>

Function z is treated as *function statement*. The result of this
statement's execution is function reference (named or anonymous). In
any case it's being added to the Global object.
I tryed to point in
<http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/349b270972a6b28b/529b6517cc56c0fe>

that ()() way is based on very particular JavaScript implementation in
Firefox which is in its turn based on sloppy wording in ECMA specs
(this fact may be confirmed by Netscape 4.5 behavior which is equal to
IE's one). So ()() still works in other browsers (means doesn't crash)
but the internal mechanics is far of what authors would expect.

Mar 14 '06 #17

Richard Cornford wrote:

VK wrote:
<snip>
I am sorry but Randy's case has to contain some extra error in it -
this is why it caused an error in IE.

<snip>

And where would those errors be? In the external file that did not
exits or in the content of the SCRIPT element that was ignored? It is
reasoning like this that makes your opinion on anything worthless.

I cannot comment on it: as I said there must be some extra factor not
revealed in the posted code. Maybe by some strange occasion the .js
file with such name existed on the poster's machine and contained a
syntax error.

It seems that I have to prove again that the sky is blue (and do not
mistype the word "blue"! - otherwise the whole proof is counted as
failed :-).

For the purity of picture I placed the test case on the Web so do not
deal with local files:
<http://geocities.com/schools_ring/tmp/test.html>

// test.html
<html>
<head>
<title>Test</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<script type="text/javascript" src="existing.js">
window.alert('Hi from Inner 1');
</script>
<script type="text/javascript" src="nonexisting.js">
window.alert('Hi from Inner 2');
</script>
</head>
<body>
</body>
</html>

// existing.js
window.alert("Hi from Outer 1");

// nonexisting.js
// doesn't exists as its name suggests.

Go study the behavior as long as you want on any browser you want.

After you are done *please* expedit the changes in the relevant FAQ
Notes section.

Mar 14 '06 #18

Randy Webb

Richard Cornford said the following on 3/14/2006 10:56 AM:

Randy Webb wrote:
<snip>
<script type="text/javascript" src="outer.js">
inner:
</script>

<script type="text/javascript" src="fileThatDidntLoad.js">
//code here
</script>

I think you have to look back at some of the older IE and NS browsers
(NS6/7) to find browsers that will execute the code block. IE6 throws an
Invalid Character error on a src file that doesn't exist.

Unfortunately if IE throws an invalid character error then you have not
tested the phenomenon as that is the symptom of the response form the
SRC request being treated as if it was javascript source. As browsers
treat whatever (non-HTTP error) response they get from the server when
they attempt to load a SRC as javascript source text, regardless of
headers, you can only test this using an HTTP server that is properly
set up to respond to a request for a missing resource with a
well-formed 404 HTTP error.

It's been so long since I looked into that I had forgotten that part of
the error. Thank you for reminding me, and yes, that would be the reason
for the error message.

It also gave me cause to read that part of the Notes. I glanced over it
quickly and have to agree with you that the way it is written is proper.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

Mar 14 '06 #19

Thomas 'PointedEars' Lahn

VK wrote:

Thomas 'PointedEars' Lahn wrote:
It gets even more strange: the above statement is not generally true.
I have reduced the problem to the following:

var x = {
y: function z() {}
};

and

// or: var x = function() {};
// that does not make a difference
function x() {};

// The following line triggers a "read error" (message; if you have
// enabled debugging)
x({
y: function z() {}
});
You would be even more amazed if you try your sample on any IE or an
old Netscape. If I'm reading your intentions right the result would be
far from expected ones: [...]

You could not possibly miss the point more that I was making. No surprise
here, though.
var x = {
y: function z() { alert("hello"); }
};
alert(z); // displays z function body
Of course it does, and more.
Function z is treated as *function statement*.
No, it is a FunctionExpression, as produced through the AssignmentExpression
production (if you only read the specs once). Because of the identifier,
which is optional per the FunctionExpression production and is used here,
there is a named reference to a Function object. One which .toString()
method returns its code. This is specified behavior, and kjs' behavior is
so far not standards compliant in that regard.

A FunctionStatement is not allowed there.
[snipped the usual nonsense based on VK's usual misconceptions
about the language]

You really should look into Occam's Razor, and apply it to the results of
your thinking process. Before you post.
PointedEars

Mar 14 '06 #20

Michael Winter

On 14/03/2006 22:35, Thomas 'PointedEars' Lahn wrote:

VK wrote:
[snip]

var x = {
y: function z() { alert("hello"); }
};
alert(z); // displays z function body
[snip]
Function z is treated as *function statement*.

No, it is a FunctionExpression, as produced through the
AssignmentExpression production (if you only read the specs once).

Yes, it is. However, with regard to variable instantiation, it acts like
a function declaration in IE.

A global variable, z, is created and initialized before the expression
is evaluated. That is,

if (typeof z == 'function') {
alert('The global variable, z, is defined.');
}
var x = {
y : function z() {}
};

will display the dialogue box in IE, but not in Fx or Op.

I believe that this is the point VK was trying to make, but failed.
Because of the identifier, which is optional per the
FunctionExpression production and is used here, there is a named
reference to a Function object.

Yes, but that identifier should not be available outside that function
body, as noted in section 13.

Of course, one could consider this "program ... syntax not described in
this specification."

[snip]

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.

Mar 15 '06 #21

Thomas 'PointedEars' Lahn

Michael Winter wrote:

On 14/03/2006 22:35, Thomas 'PointedEars' Lahn wrote:
VK wrote:
var x = {
y: function z() { alert("hello"); }
};
alert(z); // displays z function body
[snip]
Function z is treated as *function statement*.
No, it is a FunctionExpression, as produced through the
AssignmentExpression production (if you only read the specs once).

Yes, it is. However, with regard to variable instantiation, it acts
like a function declaration in IE.

ACK
[...]
I believe that this is the point VK was trying to make, but failed.
Which would still be disregarding the context completely of course,
because I was talking only about KJS, the ECMAScript/JavaScript/JScript
implementation in _KHTML_.

Because of the identifier, which is optional per the
FunctionExpression production and is used here, there is a named
reference to a Function object.

Yes, but that identifier should not be available outside that function
body, as noted in section 13.

And it is not in JavaScript 1.5+ (Gecko M3+), the Opera 6+ implementation,
or KJS (its buggy behavior with FunctionExpressions is restricted to their
being within ObjectLiterals).
Of course, one could consider this "program ... syntax not described in
this specification."

Full ACK. JavaScript 1.3, as implemented in Netscape versions 4.06 to 4.8,
exhibits the same behavior as described for IE here.
PointedEars

Mar 15 '06 #22

Randy Webb wrote:

Richard Cornford said the following on 3/14/2006 10:56 AM:
Randy Webb wrote:
<snip>
<script type="text/javascript" src="outer.js">
inner:
</script>
<script type="text/javascript" src="fileThatDidntLoad.js">
//code here
</script>

I think you have to look back at some of the older IE and NS browsers
(NS6/7) to find browsers that will execute the code block. IE6 throws an
Invalid Character error on a src file that doesn't exist.

Unfortunately if IE throws an invalid character error then you have not
tested the phenomenon as that is the symptom of the response form the
SRC request being treated as if it was javascript source. As browsers
treat whatever (non-HTTP error) response they get from the server when
they attempt to load a SRC as javascript source text, regardless of
headers, you can only test this using an HTTP server that is properly
set up to respond to a request for a missing resource with a
well-formed 404 HTTP error.

It's been so long since I looked into that I had forgotten that part of
the error. Thank you for reminding me, and yes, that would be the reason
for the error message.

It also gave me cause to read that part of the Notes. I glanced over it
quickly and have to agree with you that the way it is written is proper.

Fight even everything is lost ;-)

The relevant Notes' text is completely wrong, Yahoo! sets error page
headers properly, your test case contains some error or a patch you are
not willing to disclose.

Try this (and feel free to write your own for Gecko and others):

<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<script type="text/Jscript">
var xmlhttp = new ActiveXObject('Msxml2.XMLHTTP');
var url = 'http://geocities.com/schools_ring/tmp/nonexisting.js';
xmlhttp.open('GET', url, false);
xmlhttp.onreadystatechange=function() {
if (xmlhttp.readyState==4) {
if (xmlhttp.status==404) {
alert(xmlhttp.status);
}
}
}
xmlhttp.send('');
</script>
</head>

<body>

Mar 15 '06 #23

Randy Webb

VK said the following on 3/15/2006 2:55 AM:

Randy Webb wrote:
Richard Cornford said the following on 3/14/2006 10:56 AM:
Randy Webb wrote:
<snip>
> <script type="text/javascript" src="outer.js">
> inner:
> </script>
<script type="text/javascript" src="fileThatDidntLoad.js">
//code here
</script>

I think you have to look back at some of the older IE and NS browsers
(NS6/7) to find browsers that will execute the code block. IE6 throws an
Invalid Character error on a src file that doesn't exist.
Unfortunately if IE throws an invalid character error then you have not
tested the phenomenon as that is the symptom of the response form the
SRC request being treated as if it was javascript source. As browsers
treat whatever (non-HTTP error) response they get from the server when
they attempt to load a SRC as javascript source text, regardless of
headers, you can only test this using an HTTP server that is properly
set up to respond to a request for a missing resource with a
well-formed 404 HTTP error.

It's been so long since I looked into that I had forgotten that part of
the error. Thank you for reminding me, and yes, that would be the reason
for the error message.

It also gave me cause to read that part of the Notes. I glanced over it
quickly and have to agree with you that the way it is written is proper.

Fight even everything is lost ;-)

The relevant Notes' text is completely wrong, Yahoo! sets error page
headers properly, your test case contains some error or a patch you are
not willing to disclose.

My test case? I gave you the exact script blocks. No patch to cause the
error either. Had you read the FAQ Notes, and understood them, it would
become obvious what is happening. I tested it offline. That should be
your first hint.

Browser encounters a script tag with a src attribute.
Browser retrieves that file.
File doesn't exist.
Browser gets a 404 page in response.
Browser inserts that 404 page - as is - into the script block.
Browser throws an invalid character error.

The script block would look something like this - in memory:

<script type="text/javascript">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
.....
</script>

And that, my dear friend, is an "Invalid character" error message for you.

What the Notes describes:

Browser encounters a script tag with a src attribute.
Browser retrieves that file.
File can't be retrieved.
Server sends 404 response.
Browser realizes the file isn't available.
Browser executes the script block.

The major difference, that you missed, is in the "404 page" versus "404
response".

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

Mar 15 '06 #24

Randy Webb wrote:

What the Notes describes:

Browser encounters a script tag with a src attribute.
Browser retrieves that file.
File can't be retrieved.
Server sends 404 response.
Browser realizes the file isn't available.
Browser executes the script block.

The major difference, that you missed, is in the "404 page" versus "404
response".

And this is plain wrong from the first line to the last one.

Let's us go step by step:

1) The OP's problem: caused by the fact that it is impossible to
execute both external script and internal script:
<script src="file.js">
// statements
</script>

- all inner statements are ignored *if current UA supports src
attribute for <script> tag*.
If you have any problems with this common knowledge fact, please refer
to it as "Position 1" - so it wouldn't be mixed with other.

2) FAQ Notes statement:
<script src="file.js">
// statements
</script>
- statements will be executed if file.js is not available and this
fact is properly reported by server (over correct 404 page)

Plain wrong because if UA supports src attribute for <script> tag,
inner statements are ignored *on the page parsing stage* - so at the
moment script block is parsed by HTML parser, activated and making .js
file request - at this moment inner statements already skipped and do
not exist anymore. Parser do not hold them in some "buffer" in case if
the external resource is not available.
If you have any problems with this common knowledge fact, please refer
to it as "Position 2" - so it wouldn't be mixed with other.

3) Error page returned by server may affect on script behavior and even
cause errors. Plain wrong - as well as you seem to have a rather
specific idea about "proper 404 response". It is not a some kind of
bodyless error spirit sent by server - it is mainly the same
conventional HTML page with *headers set to right values*. The most
common on the Web Apache 404 page for example looks like:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /foobar.js was not found on this server.</p>
<hr>
<address>Apache/2.2.0 (Unix) Server at www.apache.org Port 80</address>
</body></html>

That brings back the problem with your testcase - you're trying to say
that there is nothing augmented in it, but there definitely is.

Here is a sample to try - I used Apache.org error page with guaranteed
proper headers:

<html>
<head>
<title>Myth Buster v1.0</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<script
type="text/javascript"
src="http://www.apache.org/foobar.js">
alert('VK is wrong!');
</script>
</head>
<body>
</body>
</html>

If you manage to bring the message "VK is wrong!" up by changing
response headers and content, please report your succes as "Position 3"
- so it wouldn't be mixed with other.

Mar 16 '06 #25

Randy Webb

VK said the following on 3/16/2006 2:49 AM:

Randy Webb wrote:
What the Notes describes:

Browser encounters a script tag with a src attribute.
Browser retrieves that file.
File can't be retrieved.
Server sends 404 response.
Browser realizes the file isn't available.
Browser executes the script block.

The major difference, that you missed, is in the "404 page" versus "404
response".

And this is plain wrong from the first line to the last one.

Whatever you say VK. Whatever you say. Trying to explain anything
technical to you is a waste of time.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

Mar 18 '06 #26

Randy Webb wrote:

Whatever you say VK. Whatever you say. Trying to explain anything
technical to you is a waste of time.

You don't need to explain anything. Just make the "VK is wrong!" alert
to appear by using/changing/patching the provided code:

<html>
<head>
<title>Myth Buster v1.0</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<script
type="text/javascript"
src="http://www.apache.org/foobar.js">
alert('VK is wrong!');
</script>
</head>
<body>
</body>
</html>

or by using the bogus code from
<http://jibbering.com/faq/faq_notes/script_tags.html#hsMix>

I wouldn't care if it was a "somewhere in the Web" article. But as it's
linked to the official group FAQ then this <q>utter nonsense</q> should
be corrected, don't you think?

It is not necessary to remove it completely. It could be re-written for
a very useful topic like say "Controlling external library load from
another script block". Say
<script src="external.js"></script>
<script> function internal(){} </script>
and what would be the means to detect in internal() that external.js
library is loaded or failed to load (of course 404 doesn't help here,
but at least it is doable by other means).
That would be a useful article:- I can provide the original variant for
the public "tear apart".

Mar 18 '06 #27

Randy Webb

VK said the following on 3/18/2006 3:12 AM:

Randy Webb wrote:
Whatever you say VK. Whatever you say. Trying to explain anything
technical to you is a waste of time.
You don't need to explain anything. Just make the "VK is wrong!" alert
to appear by using/changing/patching the provided code:

It has been done or it wouldn't be in the Notes.
<html>
<head>
<title>Myth Buster v1.0</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<script
type="text/javascript"
src="http://www.apache.org/foobar.js">
alert('VK is wrong!');
</script>
</head>
<body>
</body>
</html>

or by using the bogus code from
<http://jibbering.com/faq/faq_notes/script_tags.html#hsMix>
It is not Bogus. I do think it needs to be changed but not for the
reasons you give.
I wouldn't care if it was a "somewhere in the Web" article. But as it's
linked to the official group FAQ then this <q>utter nonsense</q> should
be corrected, don't you think?
Again, yes, but not for the reasons you are giving.
It is not necessary to remove it completely.
It needs to be removed.
It could be re-written for a very useful topic like say "Controlling
external library load from another script block". Say
<script src="external.js"></script>
<script> function internal(){} </script>
if(isLoaded){
alert('External file loaded');
}
else{
alert('External file not loaded');
}

Where the variable isLoaded is defined in the last line of the external
file.
and what would be the means to detect in internal() that external.js
library is loaded or failed to load (of course 404 doesn't help here,
but at least it is doable by other means).
You have the pure 100% complete code needed above. Nothing else needed.
It's quite simple and that simplicity is why I think the Notes should be
changed and no other reason.
That would be a useful article:- I can provide the original variant for
the public "tear apart".

No need, I gave it above.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

Mar 18 '06 #28

Randy Webb wrote:

if(isLoaded){
alert('External file loaded');
}
else{
alert('External file not loaded');
}

Where the variable isLoaded is defined in the last line of the external
file.

This code fails: if isLoaded is not defined at the moment of call it
will raise uncought error. You need to do either it in the old way:

if ('undefined' != typeof isLoaded) {
// library is loaded
// Operator typeof is the only operator to address
// non-existing variables without raising an error.
// A gift of "fathers" from the pre-try/catch epoch.
}

or in the new way:

try {
if (isLoaded) {...
}
catch(e) {
//
}

Mar 18 '06 #29

Randy Webb wrote:

You don't need to explain anything. Just make the "VK is wrong!" alert
to appear by using/changing/patching the provided code:
It has been done or it wouldn't be in the Notes.

It couldn't be done because never existed a browser to do it. In one of
posts in this thread I did a suggestion of how this erroneus text could
appear from reading wrongly the purpose and mechanics of some ancient
scripts (no "src" attribute fall-back).
It is not Bogus. I do think it needs to be changed but not for the
reasons you give.

You keep reffering on some misterious "background sense" of this text
while there is not such. It is simply a misunderstanding of the HTML
parser mechanics. A quote from my previous post:
"Plain wrong because if UA supports src attribute for <script> tag,
inner statements are ignored *on the page parsing stage* - so at the
moment script block is parsed by HTML parser, activated and making .js
file request - at this moment inner statements already skipped and do
not exist anymore. Parser do not hold them in some "buffer" in case if
the external resource is not available."

Then HTML parser meets opening <script> tag and sees src attribute set,
it skeeps any further parsing until it meets the closing </script> tag.
Then DOMScriptElement gets activated and making the call. At this
moment any internal statements do not exists already: they are skipped
on the previous (parsing) stage. This can be demonstrated by changing a
bit my original testcase:

<html>
<head>
<title>Myth Buster v1.0</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<script
type="text/javascript"
src="http://www.apache.org/foobar.js">
!@#$%^&*
These lines will never be parsed
if UA supports src attribute
so they will not cause an error.
*&^%$#@!
</script>
</head>
<body>
</body>
</html>

Mar 18 '06 #30

Randy Webb

VK said the following on 3/18/2006 4:31 AM:

Randy Webb wrote:
if(isLoaded){
alert('External file loaded');
}
else{
alert('External file not loaded');
}

Where the variable isLoaded is defined in the last line of the external
file.
This code fails: if isLoaded is not defined at the moment of call it
will raise uncought error.

True.
You need to do either it in the old way:
Or simply define it in the page. See below. Sometimes, you make things
harder than they have to be.
if ('undefined' != typeof isLoaded) {
// library is loaded
// Operator typeof is the only operator to address
// non-existing variables without raising an error.
// A gift of "fathers" from the pre-try/catch epoch.
}

or in the new way:
Should be interesting to see how you would determine which way to try :)
try {
if (isLoaded) {...
}
catch(e) {
//
}

Or in a better way all the way around.

<script type="text/javascript">
var isLoaded = false;
</script>
<script type="text/javascript" src="external.js"></script>
<script type="text/javascript">
if (isLoaded){
//file is loaded
}else{
//file is not loaded
}
</script>

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

Mar 18 '06 #31

Randy Webb wrote:

<script type="text/javascript">
var isLoaded = false;
</script>
<script type="text/javascript" src="external.js"></script>
<script type="text/javascript">
if (isLoaded){
//file is loaded
}else{
//file is not loaded
}
</script>

This is better :-) but it still fails: now because of timing issues. By
the moment of
if (isLoaded)
check there are 99.9% of chance that external.js is not loaded yet or
not parsed, so it will never get a chance to set isLoaded to true on
time. To keep the above approach we need to write a real loader with a
timer and define how long do we want to try before to give up:

<script type="text/javascript" src="external.js"></script>
<script type="text/javascript">
function loader(i) {
var loaded = ((typeof isLoaded == 'boolean')&&(isLoaded));
if (i < 20) {
if (loaded) {
notifyObserver(true);
}
else {
window.setTimeout('loader('+(++i)+')',500);
}
}
else {
if (loaded) {
notifyObserver(true);
}
else {
notifyObserver(false);
}
}
}

loader(0);

notifyObserver(result) {
// your code
}
</script>

In the above code we are trying to load the external file for 10sec
checking the status every 500ms.

Mar 18 '06 #32

Thomas 'PointedEars' Lahn

Richard Cornford wrote:

Randy Webb wrote:
And yes, it should be removed.

Probably not, although it may benefit from more emphasis on the
non-universal browser support instead of just the issues with proper
HTTP 404 errors and the fact that the entire technique is unnecessary
in practice.

To spare us further diversion from the point that is in question here:

I have often said (rightfully) when VK was wrong, and I will also not
hesitate to say when he is right. So, he /is/ right here.

Let's face it: The FAQ Notes are badly outdated, if not utterly wrong,
regarding this:

| The browser should handle this formulation of the script element by
| attempting to load the external file, but in the even[t] of that attempt
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| failing instead the contents of the script element are executed.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^

They will not benefit from more emphasis on the "non-universal browser
support", because no browser support of this is to be expected in the first
place. The HTML 4.01 Specification makes it very clear how this situation
MUST be handled, and so far all UAs I have tested with (which admittedly
does not include any IE-based one) follow the Specification in that regard
(and there is no `src' attribute in HTML 3.2, and previous versions are
outdated since RFC2854).

My test case[1], which was unfortunately somehow buried in discussions about
how FunctionExpressions should be handled within certain contexts, makes
that very clear. Any UA that does not follow the Specification (or the ISO
HTML Specification, which is based on it) here, is _violating_ it (there is
no SHOULD, there is a MUST). And relying on that unspecified behavior is
_potentially harmful_ (as the test results for NN4 and IE show).

This FAQ Notes section MUST be completely revised, and it MUST be made very
clear that the behavior displayed by some UAs (with naming them and their
versions explicitly) regarding this, is not standards compliant, and is not
to be expected from other UAs.
PointedEars
___________
[1] news:23****************@PointedEars.de

Mar 18 '06 #33

Thomas 'PointedEars' Lahn wrote:

I have often said (rightfully) when VK was wrong, and I will also not
hesitate to say when he is right. So, he /is/ right here.

Score adjusted: was -1000, now -990

:-D

Mar 18 '06 #34

Thomas 'PointedEars' Lahn

VK wrote:

Thomas 'PointedEars' Lahn wrote:
I have often said (rightfully) when VK was wrong, and I will also not
hesitate to say when he is right. So, he /is/ right here.
Score adjusted: was -1000, now -990

:-D

Likewise.
[...]
(and there is no `src' attribute in HTML 3.2, and previous versions are
outdated since RFC2854).

Should have been "OBSOLETE", not "outdated".
PointedEars

Mar 18 '06 #35

Randy Webb

VK said the following on 3/18/2006 7:08 AM:

Randy Webb wrote:
<script type="text/javascript">
var isLoaded = false;
</script>
<script type="text/javascript" src="external.js"></script>
<script type="text/javascript">
if (isLoaded){
//file is loaded
}else{
//file is not loaded
}
</script>
This is better :-) but it still fails: now because of timing issues. By
the moment of
if (isLoaded)
check there are 99.9% of chance that external.js is not loaded yet or
not parsed, so it will never get a chance to set isLoaded to true on
time.

If your browser does that check before the external script file is
loaded then you have a seriously flawed browser.

Test HTML:
<URL: http://members.aol.com/_ht_a/askhikk...nalJSFile.html >

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
"http://www.w3.org/TR/REC-html40/strict.dtd">
<html>
<head>
<title>External Source File Test</title>
<script type="text/javascript">
var isLoaded = false;
</script>
<script type="text/javascript" src="external.js"></script>
<script type="text/javascript">
alert(isLoaded)
</script>
<style type="text/css">
</style>
</head>
<body>
</body>
</html>

external.js:
<URL: http://members.aol.com/_ht_a/askhikk/external.js>

var begin = new Date();
for (var i=0;i<10000;i++){
var k = new Date().toString();
}
var end = new Date();
alert(end - begin)
/*
200 kilobytes of the letter k
to make the file large enough
to introduce a timing issue.
*/
var isLoaded = true;
I added the Date code just to introduce more time delay.

There are 2 alerts. The time it takes to perform the loop in the
external file and the alert(isLoaded) in the HTML file. What you are
saying is going to happen is that I get the isLoaded alert and then the
alert from the external.js file. Test it.

IE6, Opera 7, Opera 8, Opera 9 and Firefox 1.5 all give the alerts in
this order:

Time alert.
isLoaded alert.

If you have a browser that gives them in a different order, let me know.
To keep the above approach we need to write a real loader with a
timer and define how long do we want to try before to give up:
No you don't. Test the above code.

<snip>
In the above code we are trying to load the external file for 10sec
checking the status every 500ms.

And it's a wasted endeavor.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

Mar 18 '06 #36

Randy Webb wrote:

If your browser does that check before the external script file is
loaded then you have a seriously flawed browser.

I guess it is going to be a myth busting thread all the way around :-).
I'm shamefully admitting that the initial script block loading process
was not understood by me. In case of (pseudo-code):

<script>x</script>
<script src="y"></script>
<script>y</script>

it is not a set of consecutevely executed blocks as I thought. In the
reality browser creates one "big script" and inserts in this script the
sources of the declared script blocks in the order they've been
declared. Only when all blocks are retrieved (or failed to be
retrieved), browser forwards the joined source text to the script
engine.
I guess it is a right or close to the right explanation (?)

In my defence I can only tell that by the nature of my tasks I was
mainly concentrated on loaded-or-not check for dynamically added
scripts and (even more often) stylesheets. In case:

var script01 = document.createElement('SCRIPT');
script01.src = '.....';
roof.appendChild(script01);

the above spelled mechanics is not applicable (?) so one needs a timed
check out. Or of course the loaded block needs to notify somehow the
main block. (For dynamically added stylesheets that was not an option
though).

Some draft proposal could be useful (?) of standard ways of how
libraries have to notify the main block of their arrival, their name,
their version. Some standard function call or some standard object/var
check obligatory for all distributable libraries producers. (?)

Mar 19 '06 #37

Randy Webb

VK said the following on 3/19/2006 10:22 AM:

Randy Webb wrote:
If your browser does that check before the external script file is
loaded then you have a seriously flawed browser.
I guess it is going to be a myth busting thread all the way around :-).

Looks that way.
I'm shamefully admitting that the initial script block loading process
was not understood by me. In case of (pseudo-code):

<script>x</script>
<script src="y"></script>
<script>y</script>

it is not a set of consecutevely executed blocks as I thought. In the
reality browser creates one "big script" and inserts in this script the
sources of the declared script blocks in the order they've been
declared. Only when all blocks are retrieved (or failed to be
retrieved), browser forwards the joined source text to the script
engine.
I guess it is a right or close to the right explanation (?)
Close enough :) It doesn't create "one big script block" though. If you
view the normalized source of the page after it loads you will see three
script blocks.
In my defence I can only tell that by the nature of my tasks I was
mainly concentrated on loaded-or-not check for dynamically added
scripts and (even more often) stylesheets. In case:

var script01 = document.createElement('SCRIPT');
script01.src = '.....';
roof.appendChild(script01);

the above spelled mechanics is not applicable (?) so one needs a timed
check out. Or of course the loaded block needs to notify somehow the
main block. (For dynamically added stylesheets that was not an option
though).
If I were doing something like that, then script01 would have a call as
the last line to continue execution. See the "How to call a PHP script
using Javascript" thread from today. I explained it twice already in
that thread :) It kills any need for knowing when the script is loaded
as the script itself tells you.
Some draft proposal could be useful (?) of standard ways of how
libraries have to notify the main block of their arrival, their name,
their version. Some standard function call or some standard object/var
check obligatory for all distributable libraries producers. (?)

See above :)

external.js:

//lots of JS code here
functionToProcessTheAboveCode()

Where the function resides in the document itself.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

Mar 19 '06 #38

VK wrote:

parser mechanics. A quote from my previous post:
"Plain wrong because if UA supports src attribute for <script> tag,
inner statements are ignored *on the page parsing stage* - so at the
moment script block is parsed by HTML parser, activated and making .js
file request - at this moment inner statements already skipped and do
not exist anymore. Parser do not hold them in some "buffer" in case if
the external resource is not available."

Leaving everything as it is (because it is total true) it may be
necessary (?) to mention at least one escape from the traditional
<script> declaration rules: namely it is possible to not have the
closing tag for external script declaration: but only for XHTML pages
and only served with the proper application/xhtml-xml Content-Type:

<http://groups.google.com/group/comp.infosystems.www.authoring.html/tree/browse_frm/thread/6ff8329925aae8a6/28eeac314478c9fe?rnum=11&hl=en&_done=%2Fgroup%2Fco mp.infosystems.www.authoring.html%2Fbrowse_frm%2Ft hread%2F6ff8329925aae8a6%2F%3Fhl%3Den%26#doc_99a53 c0a96697191>
<quote>
So, anyway: one *can* use <script> without closing tag on a valid XHTML
page served with Content-Type application/xhtml-xml. It breaks the
search engine indexing and makes the page unavailable to IE users (at
least not available in the conventional way). But if it's a question of
life or death - then here is the way.
</quote>

Apr 13 '06 #39

Randy Webb

VK said the following on 4/13/2006 4:40 PM:

VK wrote:
parser mechanics. A quote from my previous post:
"Plain wrong because if UA supports src attribute for <script> tag,
inner statements are ignored *on the page parsing stage* - so at the
moment script block is parsed by HTML parser, activated and making .js
file request - at this moment inner statements already skipped and do
not exist anymore. Parser do not hold them in some "buffer" in case if
the external resource is not available."
Leaving everything as it is (because it is total true) it may be
necessary (?) to mention at least one escape from the traditional
<script> declaration rules: namely it is possible to not have the
closing tag for external script declaration: but only for XHTML pages
and only served with the proper application/xhtml-xml Content-Type:

You forgot to mention that you have to be using a UA that honors them both.

Use both opening and closing tags and it becomes a moot point.
<http://groups.google.com/group/comp.infosystems.www.authoring.html/tree/browse_frm/thread/6ff8329925aae8a6/28eeac314478c9fe?rnum=11&hl=en&_done=%2Fgroup%2Fco mp.infosystems.www.authoring.html%2Fbrowse_frm%2Ft hread%2F6ff8329925aae8a6%2F%3Fhl%3Den%26#doc_99a53 c0a96697191>
<quote>
So, anyway: one *can* use <script> without closing tag on a valid XHTML
page served with Content-Type application/xhtml-xml. It breaks the
search engine indexing and makes the page unavailable to IE users (at
least not available in the conventional way). But if it's a question of
life or death - then here is the way.
</quote>

If it is a life or death then you are dead for trying to use XHTML on
the web anyway.
<let the content negotiation debate start>
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

Apr 14 '06 #40

object expected error

Similar topics