«

On 30/06/2005 01:49, John Dunlop wrote:

[snip]

> The link David gave - I hadn't read it until today either -
> suggests <application/javascript> will shortly be registered.

[snip]

> Bjöern's draft, if it makes it, would render <text/javascript>
> OBSOLETE, 'no longer believed appropriate for use'. Tallyho!

It doesn't really make a difference either way. Using a type other than
text/javascript is likely to leave a script unexecuted, so the
introduction of application/javascript (and others) won't mean anything
for quite some time.

I must say I'm confused though (and I don't expect you to answer this):
ECMA standardised ECMAScript in 1997. Both JScript, JavaScript, and
others have since been implementations of that language. Considering
such widespread use, why on Earth has it taken so long to register a
MIME type? Particularly as one has been required for use in HTML since
HTML 4.0 (or thereabouts), and has been around for about as long. It
would have been significant then, but it is far too late now.

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

On Thu, 30 Jun 2005 01:35:01 GMT, Michael Winter
<> wrote:

>It doesn't really make a difference either way. Using a type other than
>text/javascript is likely to leave a script unexecuted

That's my take on the issue ... unless we're discussing what should
be, rather than what is.

Granted, I've never tried using text/js. Perhaps the browser would
just default to JavaScript, since that's likely what it'll do without
a MIME type of any kind.

Ian
--
Was it not a comedy, a strange and stupid
matter, this repetition, this running around
in a fateful circle? (Hermann Hesse)
http://www.bookstacks.org/

On 30/06/2005 02:51, Ian Rastall wrote:

> On Thu, 30 Jun 2005 01:35:01 GMT, Michael Winter
> <> wrote:
>
>> It doesn't really make a difference either way. Using a type other
>> than text/javascript is likely to leave a script unexecuted
>
> That's my take on the issue ... unless we're discussing what should
> be, rather than what is.

I'm usually partial to those debates , but I suppose the only details
I'm interested in here is why didn't this occur sooner.

> Granted, I've never tried using text/js.

I did. After all the text doesn't need to be extensive: a browser will
either do something or it won't, and neither Firefox nor IE did.

> Perhaps the browser would just default to JavaScript, since that's
> likely what it'll do without a MIME type of any kind.

That couldn't be allowed, though. There's no rule saying that
ECMAScript-derivatives are the only scripting languages permissible on
the Web. After all, IE also implements VBScript. So, to simply ignore
the type attribute when specified could result in attempts to execute a
script that truly isn't understood.

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

On Thu, 30 Jun 2005 02:06:09 GMT, Michael Winter
<> wrote:

>to simply ignore the type attribute when specified could
>result in attempts to execute a script that truly isn't understood.

True. I'm thinking of the behavior of browsers when nothing is
specified at all. But I'm a bit over my head in this discussion, truth
be told. This is getting into the realm of IETF and W3C stuff!

Ian
--
Was it not a comedy, a strange and stupid
matter, this repetition, this running around
in a fateful circle? (Hermann Hesse)
http://www.bookstacks.org/

Michael Winter wrote:

> Using a type other than text/javascript is likely to leave a script
> unexecuted, so the introduction of application/javascript (and others)
> won't mean anything for quite some time.

I can see one workaround - and that's just what it is, mind
you, a *workaround* - though it's far from ideal. Write a
custom DTD in which the <type> attribute of SCRIPT is
optional. Then you can send your javascript files with the
MIME type <application/javascript> and have them executed by
at least some browsers. Two points to note, however: (1) you
have to use external scripts (which is No Bad Thing, I hear
you say), and (2) you can't call your document HTML4.01.

--
Jock

On 30/06/2005 08:44, John Dunlop wrote:

> I can see one workaround [for unrecognised types:] Write a custom DTD
> in which the <type> attribute of SCRIPT is optional.

I don't really see that working, though. Browsers don't actually read
the DTD, so they're unlikely to care whether you want the type attribute
to be treated optionally. Moreover, and as I said to Ian, an omitted
type attribute is different from a specified, but unrecognised, MIME
type value. The former could permit a reasonable guess (some ECMAScript
derivative), but the latter must cause a script to be ignored.

> Then you can send your javascript files with the MIME type
> <application/javascript> and have them executed by at least some
> browsers.

Care to name any?

I could be wrong of course, and I would have no problem with that, but
as I see it these registrations are less than useless for the time being.

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

Michael Winter wrote:
> On 30/06/2005 08:44, John Dunlop wrote:
<snip>
>> Then you can send your javascript files with the MIME
>> type <application/javascript> and have them executed
>> by at least some browsers.
>
> Care to name any?
>
> I could be wrong of course, and I would have no problem
> with that, but as I see it these registrations are less
> than useless for the time being.

There are two very distinct aspects to this. The HTTP headers that
accompany an external JS file, and the TYPE attribute as required by
HTML in a SCRIPT element's opening tag.

Some time ago, in response to having the absence of any official MIME
type for javascript pointed out to me, I did some experiments sending JS
files to browsers with MIME types that varied from the totally
fictitious, through the utterly inappropriate, to the wrong but not too
unexpected (text/html, text/plain and the like). And I could not find a
browser that would not happily swallow and execute the script file
regardless of the MIME type asserted.

Granted I did not use any browsers as old as Netscape 3 for those test,
and I understand that Netscape 3 did have an attitude towards the MIME
type of external JS files (preferring application/x-javascript).

However, in the absence of any official MIME type for javascript it is
not surprising that browsers should appear to have a habit of disregard
that header entirely and just treating whatever is sent as potential JS
source code (which is also why 404 error pages asserting that they are
text/html still get interpreted as JS and result in apparent syntax
errors). There is little else they could reasonably do.

As a result sending application/javascript as an HTTP header would be as
insignificant as sending anything else, and so harmless (and, if
officially adopted as the correct MIME type, theoretically the right
thing to do).

The HTML TYPE attribute of SCRIPT elements was obviously necessary if
the W3C didn't want to tie web browsers to a single script type, but it
was a mistake for the HTML spec to reference an official list of MIME
types and then cite an exempt text/javascript MIME type that did not
appear in that list. The effect was to leave text/javascript as the only
possible TYPE value for use in HTML with javascript, but without any
real reason for its use except that it had been provided as an example
along side the words "Authors must supply a value for this attribute".

The practical upshot is that if a SCRIPT element is to have a TYPE
attribute, and be expected to treat its contents or referenced file as
javascript, it is going to need to be TYPE="text/javascript" to work
cross browsers (at least for the next 3 or 4 years). But then I suppose
that if TYPE is intended to express a MIME type then an HTTP header that
is also supposed to be a MIME type should probably assert the same (even
if fictional) type.

It's a mess that should have been sorted out years ago, but may now
never be satisfactorily resolved.

Richard.

Michael Winter wrote:

> On 30/06/2005 08:44, John Dunlop wrote:
>
> > I can see one workaround [for unrecognised types:] Write a custom DTD
> > in which the <type> attribute of SCRIPT is optional.

[By the way, I should've mentioned, I don't approve of my
suggestion at all. Let it be known, I'm in no way
recommending it!]

> I don't really see that working, though. Browsers don't actually read
> the DTD, so they're unlikely to care whether you want the type attribute
> to be treated optionally.

Well, that was really for the purposes of validation, to get
round SCRIPT's obligatory <type> attribute.

> Moreover, and as I said to Ian, an omitted type attribute is different
> from a specified, but unrecognised, MIME type value.

Yes. In my suggestion the <type> attribute is left out. The
only place the soon-to-be MIME type features is in the HTTP
Content-Type header.

> The former could permit a reasonable guess (some ECMAScript
> derivative), but the latter must cause a script to be ignored.

So, in your words, as it falls into the former category, my
suggestion 'could permit a reasonable guess'?


PS, where does the spec say, other than in informative notes -
and I'm *assuming* the note in sec. 6.7 is informative - that
the <type> attribute takes a value of a MIME type as defined
in RFCs2045-49? Are normative references normative if they
occur in informative notes?

--
Jock