Default Scripting Language in Browsers?

J

Jon Gómez

I was reading from the recent thread in which PointedEars uses (from
what I understand) an intrinsic event in [2]. It got me to wondering
about current practice in declaring the default script type as set out
in the HTML 4.01 specification (using Content-Script-Type), where I had
originally encountered the concept.

So I did some research. I looked through the newsgroup archives [3] and
in the notes supplement to the FAQ [1]. The notes seem to leave it to
the reader to decide whether to set a default script type.

The newsgroup posts date to 2003 and the notes for all I know are old.
Nevertheless, I suspect the situation hasn't changed much, but just in
case, I thought I'd ask.

Thanks,

Jon.



[1] FAQ for comp.lang.javascript: supplemental notes

"The Default Language for Intrinsic Events"
http://www.jibbering.com/faq/faq_notes/script_tags.html#hsEhD


[2] Recent post by PointedEars. Apr 2009.

"Re: page level onclick - can I detect nearest word"
http://groups.google.com/group/comp.lang.javascript/msg/15fa540fdb0062ee

[3] Old posts in 2003.

Lasse Reichstein Nielsen
"Does all javascript (like location.href) require that javascript be
declared?"
http://groups.google.com/group/comp.lang.javascript/msg/a3a905bbff223b40

PointedEars.
"IE error using setTimeout and Select Tag in a frame."
http://groups.google.com/group/comp.lang.javascript/msg/ceda365d881a078c
 
B

Ben Crowell

Jon said:
I was reading from the recent thread in which PointedEars uses (from
what I understand) an intrinsic event in [2]. It got me to wondering
about current practice in declaring the default script type as set out
in the HTML 4.01 specification (using Content-Script-Type), where I had
originally encountered the concept.

So I did some research. I looked through the newsgroup archives [3] and
in the notes supplement to the FAQ [1]. The notes seem to leave it to
the reader to decide whether to set a default script type.

The newsgroup posts date to 2003 and the notes for all I know are old.
Nevertheless, I suspect the situation hasn't changed much, but just in
case, I thought I'd ask.

If you have a page written in html 4 strict with

<script src="Foo.js"></script>

in it and run it through the html validator at
http://validator.w3.org/ , it will give you this stern
warning:

required attribute "TYPE" not specified

The attribute given above is required for an element that you've used,
but you have omitted it. For instance, in most HTML and XHTML document
types the "type" attribute is required on the "script" element and the
"alt" attribute is required for the "img" element.

Typical values for type are type="text/css" for <style> and
type="text/javascript" for <script>.

Considering that the w3c is in the business of setting standards for
html, I would tend to believe them when they say the type= is officially
required, and the best choice is text/javascript. The 2006 edition of
the rhino book says on p. 245 that text/javascript is the only choice
that is both blessed by a standard (RFC 4329) and supported by current
browsers.
 
J

Jon Gómez

Ben said:
If you have a page written in html 4 strict with

<script src="Foo.js"></script>

in it and run it through the html validator at
http://validator.w3.org/ , it will give you this stern
warning:

required attribute "TYPE" not specified

The attribute given above is required for an element that you've used,
but you have omitted it. For instance, in most HTML and XHTML document
types the "type" attribute is required on the "script" element and the
"alt" attribute is required for the "img" element.

Typical values for type are type="text/css" for <style> and
type="text/javascript" for <script>.

Considering that the w3c is in the business of setting standards for
html, I would tend to believe them when they say the type= is officially
required, and the best choice is text/javascript. The 2006 edition of
the rhino book says on p. 245 that text/javascript is the only choice
that is both blessed by a standard (RFC 4329) and supported by current
browsers.

Yes. However, I was asking about something else, though. I was talking
about cases where you have pieces of script without a script tag, in
which case you can't set a type attribute. Thanks for testing that for
me, though.

Jon.
 
J

Jon Gómez

Ben Crowell wrote: [...]
The 2006 edition of
the rhino book says on p. 245 that text/javascript is the only choice
that is both blessed by a standard (RFC 4329) and supported by current
browsers.


Even if it wasn't related to my question, the info on the RFC helps me
with something else. Thanks a bunch for that.

Jon.
 
D

David Mark

Jon said:
I was reading from the recent thread in which PointedEars uses (from
what I understand) an intrinsic event in [2].  It got me to wondering
about current practice in declaring the default script type as set out
in the HTML 4.01 specification (using Content-Script-Type), where I had
originally encountered the concept.
So I did some research.  I looked through the newsgroup archives [3] and
in the notes supplement to the FAQ [1].  The notes seem to leave it to
the reader to decide whether to set a default script type.
The newsgroup posts date to 2003 and the notes for all I know are old.
Nevertheless, I suspect the situation hasn't changed much, but just in
case, I thought I'd ask.

If you have a page written in html 4 strict with

   <script src="Foo.js"></script>

in it and run it through the html validator athttp://validator.w3.org/, it will give you this stern
warning:

   required attribute "TYPE" not specified

That is an error, not a warning. The markup is invalid.
   The attribute given above is required for an element that you've used,
   but you have omitted it. For instance, in most HTML and XHTML document
   types the "type" attribute is required on the "script" element andthe
   "alt" attribute is required for the "img" element.

   Typical values for type are type="text/css" for <style>  and
   type="text/javascript" for <script>.

Considering that the w3c is in the business of setting standards for
html, I would tend to believe them when they say the type= is officially
required, and the best choice is text/javascript. The 2006 edition of
the rhino book says on p. 245 that text/javascript is the only choice
that is both blessed by a standard (RFC 4329) and supported by current
browsers.

If so, it is yet another reason not to recommend that book. The
attribute is required, yet there is no standard for it. That being
said, "text/javascript" is the only choice if you are to have valid
markup.
 
B

Ben Crowell

Jon said:
Ben Crowell wrote: [...]
The 2006 edition of
the rhino book says on p. 245 that text/javascript is the only choice
that is both blessed by a standard (RFC 4329) and supported by current
browsers.


Even if it wasn't related to my question, the info on the RFC helps me
with something else. Thanks a bunch for that.

Glad it helped. Sorry, I went back and reread your post more carefully
after posting my reply, and realized that it wasn't actually what you
were asking about :)
 
D

David Mark

<sarcasm> I am sure that your upcoming book will supplant the Rhino as
the standard reference work.</sarcasm>

Certainly an odd use of that tag. Halfwit seems more appropriate.

The fact remains that the cited assertion is completely false.
Standard reference or no standard reference. And FYI, I am not
writing a reference book.
 
T

Thomas 'PointedEars' Lahn

Osmo said:
Not so. The type attribute is required for validity, not the specific
attribute value. Any content type is valid:

http://www.w3.org/TR/html401/interact/scripts.html#edef-SCRIPT

Understand that the W3C Validator is a *syntax* checker which validates
against a DTD, not against the equally normative prose of the Specification
(unless marked as "informative") of the declared or inferred markup language.

The markup is not Valid if the `type' attribute is missing, the attribute
value is missing, or the value does not contain solely a value in the MIME
media type (not: content type) format (see RFC 2046). So no, *any* "content
type" will _not_ suffice.

As for compatibility, the following is yet to be updated but still relevant:

<http://PointedEars.de/scripts/test/mime-types/>


PointedEars
 
D

David Mark

Not so. The type attribute is required for validity, not the specific
attribute value. Any content type is valid:

http://www.w3.org/TR/html401/interact/scripts.html#edef-SCRIPT

You misunderstood my comment. Assuming you want your script to run,
your two choices are:

<script>

<script type="text/javascript">

The first is invalid and the attribute value can't be empty, so "text/
javascript" is the only choice. As I mentioned, there is no standard
for the value.
 
O

Osmo Saarikumpu

Thomas said:
Understand that the W3C Validator is a *syntax* checker which validates
against a DTD, not against the equally normative prose of the Specification
(unless marked as "informative") of the declared or inferred markup language.

I think this was understood.
The markup is not Valid if the `type' attribute is missing, the attribute
value is missing, or the value does not contain solely a value in the MIME
media type (not: content type) format (see RFC 2046). So no, *any* "content
type" will _not_ suffice.

This I don't understand. As I said, for the sake of validity, the type
attribute must be present and I understand that the attribute value can
not be e.g. an empty string (type="", which would be syntactically
valid, but against prose). But, I don't see why type="text/vbscript"
would not be valid when type="text/javascript" would. Sorry to say, but
reading RFC 2046 did not help.

Best wishes,
Osmo
 
O

Osmo Saarikumpu

You misunderstood my comment. Assuming you want your script to run,
your two choices are:

<script>

<script type="text/javascript">

I guess I did, but perhaps it's because you said: <q>"text/javascript"
is the only choice if you are to have valid markup.</q>

I understood that the issue was validity, not execution.
The first is invalid and the attribute value can't be empty, so "text/
javascript" is the only choice. As I mentioned, there is no standard
for the value.

I don't follow. Please, why e.g. "text/jscript" would not be a (valid)
choice?

Best wishes,
Osmo
 
D

David Mark

I guess I did, but perhaps it's because you said: <q>"text/javascript"
is the only choice if you are to have valid markup.</q>

I understood that the issue was validity, not execution.

You missed my point again. There are two choices (as listed
previously.) One is valid, the other is not. If you pick the valid
one, you have but one (sane) choice for its value.
I don't follow. Please, why e.g. "text/jscript" would not be a (valid)
choice?

Yes, that's not it as most browsers have no idea what jscript is.
 
T

Thomas 'PointedEars' Lahn

Osmo said:
This I don't understand. As I said, for the sake of validity, the type
attribute must be present and I understand that the attribute value can
not be e.g. an empty string (type="", which would be syntactically valid,
but against prose). But, I don't see why type="text/vbscript" would not
be valid when type="text/javascript" would. Sorry to say, but reading RFC
2046 did not help.

Good question! `text/vbscript' is not a Valid attribute value indeed,
because it does not meet the requirements of HTML 4.01 as it cannot be
produced by the grammar in RFC 2045, section 5.1. See also
<http://www.iana.org/assignments/media-types/text/> where `vbscript'
is not listed.

What matters here, of course, is that the outcome would be a lot different.


PointedEars
 
O

Osmo Saarikumpu

David said:
You missed my point again. There are two choices (as listed
previously.) One is valid, the other is not. If you pick the valid
one, you have but one (sane) choice for its value.

I guess it's because I saw more than two choices and I did not see that
you were inferring valid === sane.
Yes, that's not it as most browsers have no idea what jscript is.

I thought that this was by design, the idea being that one could
introduce a scripting language, say type="foo/bar" and leave it to the
browser to support it ot not. Trivial example:

<script type="text/jscript">
/*The code would be executed by some
browsers, but not by others.*/
</script>

As stated before, I'm unable to see why the above script element would
not be *valid*?

Best wishes,
Osmo
 
O

Osmo Saarikumpu

Thomas said:
Good question! `text/vbscript' is not a Valid attribute value indeed,
because it does not meet the requirements of HTML 4.01 as it cannot be
produced by the grammar in RFC 2045, section 5.1.

I'll have to take your word for that, 'cause I can't understand none of
it. From that RFC I can't even see if "text/javascript" would be valid.
See also
<http://www.iana.org/assignments/media-types/text/> where `vbscript'
is not listed.

And, if I'm not completely lost, it would seem to say that
"text/javascript" is obsolete?
What matters here, of course, is that the outcome would be a lot different.

Which was my point: valid, but different outcome, by design. I was under
the impression that the type attribute's value was left open mainly for
future implementations.

Best wishes,
Osmo
 
D

David Mark

I guess it's because I saw more than two choices and I did not see that
you were inferring valid === sane.

I was inferring nothing of the sort. Read it again.
I thought that this was by design, the idea being that one could
introduce a scripting language, say type="foo/bar" and leave it to the
browser to support it ot not. Trivial example:

<script type="text/jscript">
/*The code would be executed by some
browsers, but not by others.*/
</script>

As stated before, I'm unable to see why the above script element would
not be *valid*?

Nobody said it wasn't. It is insane though. :)
 
O

Osmo Saarikumpu

Nobody said it wasn't. It is insane though. :)

I must be very dense, but I'm unable how the following could be
misunderstood?

<q>
"text/javascript" is the only choice if you are to have valid
markup.
</q>

Markup wise valid is valid, i.e.:

<script type="example">
//Not tested, but surely valid:
var valid = (passes technical validation) &&
(is according to the prose of the specification);
</script>

Best wishes,
Osmo
 
D

David Mark

 >> element (type="text/jscript") would not be *valid*?


I must be very dense, but I'm unable how the following could be
misunderstood?

Me either.
<q>
"text/javascript" is the only choice if you are to have valid
markup.
</q>

You are quoting out of context and I already explained this to you.
Markup wise valid is valid, i.e.:

<script type="example">
//Not tested, but surely valid:
var valid = (passes technical validation) &&
             (is according to the prose of the specification);
</script>

We are talking about Javascript. The fact remains that "text/
javascript" (not "example") is your only choice if you want valid
markup (the other is to leave off the type attribute, which is
invalid.)

As we already went over, there is a third choice, but it is only for
those who do not wish to have their scripts execute.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,768
Messages
2,569,574
Members
45,048
Latest member
verona

Latest Threads

Top