Default Scripting Language in Browsers?

[Thomas 'PointedEars' Lahn]

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.

Let's have a closer look at the relevant productions then.

The HTML 4.01 Specification[1] defines the following requirements for the
`type' attribute of the SCRIPT element. In the DTD:

| <!ATTLIST SCRIPT
| [...]
| type %ContentType; #REQUIRED -- content type of script language --

| <!ENTITY % ContentType "CDATA"
| -- media type, as per [RFC2045]
| -->

In the prose:

| 6.7 Content types (MIME types)
|
| Note. A "media type" (defined in [RFC2045] and [RFC2046]) specifies
| the nature of a linked resource. This specification employs the term
| "content type" rather than "media type" in accordance with current
| usage. Furthermore, in this specification, "media type" may refer to
| the media where a user agent renders a document.
|
| This type is represented in the DTD by %ContentType;.
|
| Content types are case-insensitive.
|
| Examples of content types include "text/html", "image/png", "image/gif",
| "video/mpeg", "text/css", and "audio/basic". For the current list of
| registered MIME types, please consult [MIMETYPES].

And:

,-[RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: ]
| [ Format of Internet Message Bodies ]
|
| 5.1. Syntax of the Content-Type Header Field

(Insofar, I stand corrected. It is acceptable to call the required value
for the `type' attribute of the SCRIPT element a "content type" instead of
"(MIME) media type".)

| In the Augmented BNF notation of RFC 822, a Content-Type header field
| value is defined as follows:
|
| content := "Content-Type" ":" type "/" subtype
| *(";" parameter)
| ; Matching of media type and subtype
| ; is ALWAYS case-insensitive.
|
| type := discrete-type / composite-type
|
| discrete-type := "text" / "image" / "audio" / "video" /
| "application" / extension-token

So `text' of `text/vbscript' can be produced by `type'. However:

| extension-token := ietf-token / x-token
|
| ietf-token := <An extension token defined by a
| standards-track RFC and registered
| with IANA.>
|
| x-token := <The two characters "X-" or "x-" followed, with
| no intervening white space, by any token>
|
| subtype := extension-token / iana-token
|
| iana-token := <A publicly-defined extension token. Tokens
| of this form must be registered with IANA
| as specified in RFC 2048.>

`vbscript' cannot be produced by `subtype' because it is neither can be
produced by `extension-token' (AFAICS) nor by `iana-token':

And, if I'm not completely lost, it would seem to say that
"text/javascript" is obsolete?

It has been *marked* as obsolete, prematurely, due to a (probably
well-intentioned) individual with, however, a doubtful level of experience
about the subject to be defined. In any case, an "obsolete" type is still
*registered* at IANA, and therefore Valid.

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.

Yes, but of course in accordance with the IETF/IESG process.


PointedEars
___________
[1] <http://www.w3.org/TR/REC-html40/interact/scripts.html#h-18.2.1>

 

[Dr J R Stockton]

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.

Never trust a technical document which is undated and/or has no adequate
indication within itself of authorship or maintenance. The lack of such
information means that the author does not understand what is necessary
for trustworthy communication.

You can tell the last upload date of the document - which may not
correspond to significant maintenance - by Firefox Tools, Page Info or
Right-click, View Page Info. the FAQ page that you cited is 2006-02-13.

 

[Dr J R Stockton]

In comp.lang.javascript message <e7c2b719-af05-4a47-b62a-8d3bfa8c24ae@q9
g2000yqc.googlegroups.com>, Mon, 6 Apr 2009 21:20:06, David Mark

On Apr 7, 12:09 am, Ben Crowell

Your "the rhino book" is not a sufficient reference unless you have
checked all past editions. Moreover, IIRC, both books mentioned in the
current FAQ have a rhino on the cover; but their contents are by no
means the same. One of them may be supposed to be approximately
equivalent to the flamingo book, at 1.85 kg; the other is a mere 0.1 kg.

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.

RFC 4329 defines "text/javascript", and includes "This document thus
defines text/javascript ..." (albeit more loosely that it defines
"text/ecmascript"). But perhaps DM did not bother to look at it.


To the OP : Do not be too influenced by reading the standards. They are
like the Ten Commandments, handed down from Above for all to obey. But
if you consult your local policeman or newspapers, you will discover
that such obedience is not universal, even among non-politicians.

What matters to a Web programmer is what current and recent software
actually does, and what future software seems likely to do; for that,
the standards are a useful guide, but no more.

Effectively, all browsers except IE will take all <script> as equivalent
to <script type="text/javascript">; there is no need to use anything
other than one of those at present.

IE also recognises text/vbscript (and ought to recognise text/jscript;
but I've not checked that). In IE, <script> is equivalent to whichever
of /javascript or /vbscript was most recently used, with /javascript
being the initial default. Error handlers use the most recent of those,
with some interpretation of recent.

Validators recognise that standards require type=something; since it is
clearly better not to have validation results cluttered by unimportant
known matter, one should, in proper pages, use type="text/javascript" or
type="text/vbscript".


Except that RFC4329 April 2006 clearly prefers
type="application/javascript" and
type="application/ecmascript", so one of those ideally should be used
instead, IF IT CAN BE ESTABLISHED that all relevant software accepts it.


Using text/vbscript is only appropriate on an IE-only intranet, or on
Web pages whose prime purpose includes demonstrating, or another
specific need to use, VBscript.

 

[David Mark]

On Apr 8, 7:13 am, Dr J R Stockton <[email protected]>
wrote:

[snip]

RFC 4329 defines "text/javascript", and includes "This document thus
defines text/javascript ..." (albeit more loosely that it defines
"text/ecmascript").  But perhaps DM did not bother to look at it.

Scare to even invoke my name, doc? LOL.

From your reference:

"This memo provides information for the Internet community. It does
not specify an Internet standard of any kind."

Right at the top. Thank you.

[snip]

 

[Eric Bednarz]

[RFC 4329]

"This memo provides information for the Internet community. It does
not specify an Internet standard of any kind."

At least it informs you that some 8 years after HTML 4, you have a
conforming way to satisfy some pointless, Quixotic SGMLese requirement
in HTML.

Right at the top. Thank you.

Right. I hope that from now on half-wits who brag about ‘valid HTML’
will refer to the external document type declaration subset of the
international standard, not that of some stinky W3C recommendation.

 

[John G Harris]

To the OP : Do not be too influenced by reading the standards. They are
like the Ten Commandments, handed down from Above for all to obey. But
if you consult your local policeman or newspapers, you will discover
that such obedience is not universal, even among non-politicians.

That must be very comforting to the policeman who's about to be sent to
jail for doing 90 in a 30 limit (and killing someone).

What matters to a Web programmer is what current and recent software
actually does, and what future software seems likely to do; for that,
the standards are a useful guide, but no more.

<snip>

So, 1900 was a Leap Year and nuts to all those standards written by
wild-eyed academics.

John

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
8924D9443D28E23ED5CD>, Thu, 9 Apr 2009 10:56:06, John G Harris

That must be very comforting to the policeman who's about to be sent to
jail for doing 90 in a 30 limit (and killing someone).

That remark seems both tasteless and pointless.

<snip>

So, 1900 was a Leap Year and nuts to all those standards written by
wild-eyed academics.

It has commonly been thought, in a country a few thousand kilometres to
our West (and a little Southwards) that 1900 was a Leap Year. Some of
them also believed that February 2000 would have 30 days. Show some Web
software that has such behaviour, and you will have demonstrated the
need for those who write Web code to code for or around such
idiosyncrasies. Indeed, those who use VBScript dates, or Delphi ones,
etc., are already doing so, whether they know it or not. Their dating
was intended to count days from 1901-01-01 = 1, including 1900 Feb 29.
That is why Delphi and VBscript Day Zero is 1899-12-30.

1900 was a Leap Year in Albania, Bulgaria, Estonia, Greece, Latvia,
Lithuania, Romania, Great Imperial Russia, and what became Yugoslavia.

Where browsers are wrong, Web programmers who want their code to give
correct results must work around that. All the better, of course, if
the work-round uses only code compliant with ECMA-262-3.

 

[Jon Gómez]

Never trust a technical document which is undated and/or has no adequate
indication within itself of authorship or maintenance. The lack of such
information means that the author does not understand what is necessary
for trustworthy communication.

You can tell the last upload date of the document - which may not
correspond to significant maintenance - by Firefox Tools, Page Info or
Right-click, View Page Info. the FAQ page that you cited is 2006-02-13.

Thanks for the suggestion about checking the date. In this case,
though, I think there may have been a post a while back about such a
date being wrong for one of the FAQ pages... I'd have to search the
archives.

Jon.

 

[Osmo Saarikumpu]

Let's have a closer look at the relevant productions then.

Thank you.

`vbscript' cannot be produced by `subtype' because it is neither can be
produced by `extension-token' (AFAICS) nor by `iana-token':

I think I see some light I was able to track down the root of my
error to the HTML 4 spec: '... where "type" is an content type naming
the scripting language. Examples of values include "text/tcl",
"text/javascript", "text/vbscript".'¹

I guess I had read that as: "Examples of valid values..." ;-)

It has been *marked* as obsolete, prematurely, due to a (probably
well-intentioned) individual with, however, a doubtful level of experience
about the subject to be defined. In any case, an "obsolete" type is still
*registered* at IANA, and therefore Valid.

I see. Thank you again for your trouble.

Best wishes,
Osmo

¹
http://www.w3.org/TR/1998/REC-html40-19980424/interact/scripts.html#h-18.2.2

 

[Thomas 'PointedEars' Lahn]

I think I see some light I was able to track down the root of my
error to the HTML 4 spec: '... where "type" is an content type naming
the scripting language. Examples of values include "text/tcl",
"text/javascript", "text/vbscript".'¹

I guess I had read that as: "Examples of valid values..." ;-)

Yes, it is very important indeed to keep in mind that examples in technical
specifications are never normative. Examples in the HTML 4.01 Specification
in particular contain/are a number of ridiculous blunders that should never
make it on any Web site.


Regards,

PointedEars

 

[Osmo Saarikumpu]

Examples in the HTML 4.01 Specification
in particular contain/are a number of ridiculous blunders that should never
make it on any Web site.

Tell me about it! Should had been warned with following grammar:

"is an content"

but no... I guess that in 1998 I thought that they were infallible.

Easter regards,
Osmo