By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,758 Members | 1,223 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,758 IT Pros & Developers. It's quick & easy.

mimetype text/javascript obsolete?

P: n/a
Hi,

Can anybody comment on this?
In comp.lang.php I advised somebody to skip using:
<script language="javascript">
and use:
<script type="text/javascript">

And mr. Dunlop gave this response:
The MIME type registry marks text/javascript as
obsolete. Are there any browser issues with the MIME type
application/javascript?

http://www.iana.org/assignments/media-types/text/
No I am curious. I just got out of the bad habbit of using
language="javascript", and now type="text/javascript" is marked obsolete.
;-)

Any comments on this?

Regards,
Erwin Moller
Jan 17 '07 #1
Share this Question
Share on Google+
9 Replies


P: n/a
ASM
Erwin Moller a écrit :
And mr. Dunlop gave this response:
The MIME type registry marks text/javascript as
obsolete. Are there any browser issues with the MIME type
application/javascript?

http://www.iana.org/assignments/media-types/text/
Any comments on this?
My IE Mac run only text/javascript
My FF2 run with both
Didn't try with my other browsers

--
Stephane Moriaux et son (moins) vieux Mac déjà dépassé
Jan 17 '07 #2

P: n/a
Erwin Moller wrote:
In comp.lang.php I advised somebody to skip using:
<script language="javascript">
and use:
<script type="text/javascript">
That advice makes sense if you look at the HTML 4.01 or XHTML 1.0
specification where the type attribute on the script element is
mandatory while the language attribute is deprecated. So to have valid
HTML 4.01 or XHTML 1.0 markup you script elements need to have a type
attribute.
On the other hand that type attribute was introduced to allow
standarized MIME types as type names only text/javascript is used at
several places in the HTML 4.01 specification but was not a registered
MIME type when the HTML 4.01 specification was published and that status
remained that way for several years.
<http://www.rfc-editor.org/rfc/rfc4329.txtchanged that, so
text/javascript (and text/ecmascript which the SVG 1.0/1.1 specification
uses) are now officially registered MIME types but they have at the same
time been obsoleted in favor of application/javascript and
application/ecmascript.
--

Martin Honnen
http://JavaScript.FAQTs.com/
Jan 17 '07 #3

P: n/a
Erwin Moller wrote:[quote]
Can anybody comment on this?
In comp.lang.php I advised somebody to skip using:
<script language="javascript">
and use:
<script type="text/javascript">

And mr. Dunlop gave this response:
The MIME type registry marks text/javascript as
obsolete. Are there any browser issues with the MIME type
application/javascript?
<snip>

The registration of application/javascript happened in the middle of
last year. No browser release prior that will have any reason to
recognise application/javascript in a TYPE attribute as having anything
to do with javascript (while text/javascript is used in that context in
the HTML spec and so if a browser has an interest in the TYPE
attribute's value it can be expected to recognise text/javascript).
No I am curious. I just got out of the bad habbit of using
language="javascript", and now type="text/javascript" is marked obsolete.
;-)

Any comments on this?
It will be 3-5 years before it could be considered safe to use
application/javascript in a TYPE attribute of a SCRIPT element in a
general context. It may make sense to use application/javascript in the
content-type headers of external JS resources because for years
browsers have been ignoring content-type headers (at least the MIME
aspects of them), probably as a result of there being no official MIME
type to look for in a header. If they stop ignoring the content type
asserted by headers they will then likely start looking for one of the
recently introduced ones, including application/javascript.

Richard.

Jan 17 '07 #4

P: n/a
VK
Erwin Moller wrote:
I just got out of the bad habbit of using
language="javascript", and now type="text/javascript"
is marked obsolete.
;-)

Any comments on this?
That is a kind of rwar topic, so the following is my personal point of
view that doesn't imply any kind of consensus behind it.

As of the year 2007 the most suggested way to insert script elements on
your page is
<script>
// your code
</script>
or
<script src="file.js"></script>

Any indication of language or type is discouraged as superfluous and
useless.

The _only_ exception from this rule is some MSIE-only solution where on
the same page one has both VBScript and JScript elements. In this case
and if the first element on the page is type="VBScript" then all other
elements without type indication will be treated as VBScript sources.
Even more importantly all intrinsic event handlers like onclick="" etc.
will be treated as VBScript sources. Obviously if one has handlers
written in JScript, she gets nothing by syntax errors around.

This way:

1) If you have JavaScript only on your page (inline or over src) then
any indication of language or type is discouraged as superfluous and
useless.

2) If you have both JScript and VBScript on one page but all your
intrinsic event handlers are written in JScript then be on the safe
side: as the very first script element on your page - in the head
section - place:
<script type="text/jscript">
/* This bogus script element if placed as the very first
* ensures that event handlers on your page will be read
* as JScript and not as VBScript.
*/
</script>
- surely the comment block is not necessary, feel free to leave just
<script type="text/jscript"></script>
but _please_ do _not_ use that ugly hack
<script type="text/jscript" />

Note: Using the moment I want to repeat: i) yes, it is an ugly hack,
demonstrating a lack of basic (X)HTML knowledge and ii) no, you cannot
use this hack unless for very particular circumstances covering lesser
than 1% of situations.

Respectively after that for each script element indicate either
type="text/vbscript" or type="text/jscript".

Actually this nuance is so MSIE+ASP+intranet specific that pretty much
irrelevant for WWW projects. Yet let's us mention it.

So if you have JavaScript/JScript only on your page (inline and/or over
src) then any indication of language or type is discouraged as
superfluous and useless.

Now what about "text/javascript" and "application/javascript" from the
official standard perspective?

First of all "text/javascript" is not a MIME types and never was such.
It is a MIME-looking string recognized by all modern browsers as script
element _attribute_. The only real MIME type ever used anyhow widely is
application/x-javascript associated by default with .js extension on
Microsoft IIS servers. But don't you ever try to set
type="application/x-javascript" even for IE: it doesn't know of such
_attribute_ though it knows about such MIME type. As the result while
for external scripts type attribute with any value is simply ignored,
for inline script blocks it will lead to them being ignored.
Also with external files just for fun of it you can serve even
application/octet-stream and UA couldn't care lesser. The handling of
javascript sources by Content-Type is abandoned years ago as high
security risk. When retrieving a file indicated in <script
src="file.ext"></scriptevery UA relies on its own internal security
check and protection. There are not any perspectives that people will
get better than they are now, so no expectations of any security relief
in the future years.

That moves the topic twenty or so levels down.
The question is then what _element attribute value_ should one use if
the suggested best way
<script>
// your code
</script>
or
<script src="file.js"></script>
just doesn't go with her ideas of right and wrong.

In this case use type="text/javascript". This is the only attribute
value universally understood by all browsers including IE. Attribute
value "application/javascript" is _not_ supported on the absolute
majority of browsers including but not limited by IE.
>From any practical point of view it is enough as an argument to send to
the deepest corner of hell anyone who suggests using
"application/javascript".

Still as long as the task is to cover all issues let's us answer to two
questions:

1) is "text/javascript" is obsolete as the standard script type
attribute value?
2) is "application/javascript" is some new standard as script type
attribute value?
(Earlier it was explained that in any case it is not related anyhow
with MIME questions).

1) is "text/javascript" is obsolete as standard script type attribute
value?
Hardly, because something that never existed cannot get obsolete.
"text/javascript" never was a standard script type attribute value, it
was the "most common usage". This way "application/javascript" cannot
obsolete it. The max "application/javascript" can be is
"standard-endorsed replacement to current usage"

2) is "application/javascript" is some new standard as script type
attribute value?
This is more complicated question where first I need to explain the
nature of RFC.

RFC is Request For Comments and by its "legal status" any RFC is on the
same level as my post you are reading right now. It is a formally
stated opinion of an individual or a group of individuals of how this
or that should be done and asking of what do others think about it.
Anyone can follow the publishing procedure (see details at
<http://www.rfc-editor.org/howtopub.html>) and if passed I-D (Internet
Draft) stage then it becomes one more of RFCs.
Does it become a _standard_ immediately to follow? No more than my
current instructions do not use any language or type attributes will
become such after I press "Send".
I-D RFC procedure has to correspond to the established formal format
criteria. There is not some international technical committee for a
profound expertise. Just like some people manage to patent from time to
time perpetuum mobile, one could manage to create "Best Practice" RFC
say suggesting to set TCP/IP packet length using the provided random
number generation algorithm. RFC archives contain many documents
demonstrating nothing but limits of human's bizarrity or vanity.
At the same time there are many RFC which are indisputable core of the
modern Internet. This is because of the unique nature of the Internet
and especially of the World Wide Web. This is a system with a
tremendous positive link and with almost zero negative link. It means
that if someone suggests or invents something and this something is
really needed, the process of duplication and adoption will go in
geometrical progression. Sometimes it takes lesser than one month when
a single program with sketchy specs being reproduced and used across
all wired world. This is the positive link. But if the positive link
worked out, no one - including the original specs author - has power to
change anything a day later. He himself and all new comers have nothing
to do but follow the original specs otherwise no one recipient will
understand them. IMO the most pictorial sample of this positive vs.
negative link disproportion is HTTP "Referer" header. The typo was
noticed I believe in less than a week after HTTP/1.0 server source and
specs posted, but even then it was too late to change anything, as it
was used on too many servers around the world. The only option was to
introduce special "HTTP grammar" where a referrer is written with one
"r".

Now it comes to Bjoern Hoehrmann, The Man Who Decided To Change The
Internet Alone. :-) Since 2001 he has an idee fix to application'ize
script type attribute value and the last year his initial I-D was
promoted into RFC#4329 <http://www.ietf.org/rfc/rfc4329.txt>
What effect will it produce onto Internet standards? The most strange
things may happen of course but IMO it remains forever what it is right
now: a collection of wasted electrons.
At the same time I am expecting some confusion from time to time for a
while. Now "Internet boomers" are representing the most active part
of the Internet: thus who was too young at the time of the Internet
explosion and now is finishing college or going on the first payroll.
They used to see references to core RFCs as a definitive argument, so
for many of them _any_ RFC is a law to obey as long as it's RFC. Some
people punished by the seventh sin are using it and they will use it:
so pushing whatever RFC to be published and then run around with it
like a plaintiff with subpoena. Boldly send them to hell - until
Internet's positive link worked out there is no law of any kind behind
of them.

As a positive sample I would suggest to work closely by RFC#4627
<http://www.ietf.org/rfc/rfc4627.txtis you are dealing with JSON data
format. Again: not just because it's RFC, such argument is worthless.
But JSON is on popularity growth and if the "positive link explosion"
happens then RFC#4627 will become the same authority as say RFC#2616.

Jan 17 '07 #5

P: n/a
Hi,

Thank you all (ASM, Martine, Richard and VK) for your excellent answers.
I see a lot more context now.
(I particularry liked VK's relativation of the RFC's status, which is indeed
considered by some as The Last Authority.)

My conclusion: I'll keep using type="text/javascript" for the time being.

Thanks for your time!

Regards,
Erwin Moller
Jan 18 '07 #6

P: n/a
Can anybody comment on this?
In comp.lang.php I advised somebody to skip using:
<script language="javascript">
and use:
<script type="text/javascript">

And mr. Dunlop gave this response:
The MIME type registry marks text/javascript as
obsolete. Are there any browser issues with the MIME type
application/javascript?

http://www.iana.org/assignments/media-types/text/

No I am curious. I just got out of the bad habbit of using
language="javascript", and now type="text/javascript" is marked obsolete.
;-)
I recommend

<script>

It works on all browsers, old and new. Browsers will always do the right thing
with it.

http://javascript.crockford.com/script.html
Jan 18 '07 #7

P: n/a
Douglas Crockford wrote:
I recommend
<script>
It works on all browsers, old and new. Browsers will always do the
right thing with it.
Dear Mr. Crockford,

Your common-sense, real-world answers are not welcome here. Such nonsense
keeps the spec-quoting elitist zealots from pumping up their ego!

;)

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Jan 18 '07 #8

P: n/a
VK
Matt Kruse wrote:
Dear Mr. Crockford,

Your common-sense, real-world answers are not welcome here. Such nonsense
keeps the spec-quoting elitist zealots from pumping up their ego!

;)
Where is the needed P.S.? I guess I have to write it myself:

"P.S. It seems especially alien near of regular lack of common sense
and practical experience demonstrated Nth time in this thread by VK".

:-)

Jan 18 '07 #9

P: n/a
VK
VK wrote:
The _only_ exception from this rule is some MSIE-only solution where on
the same page one has both VBScript and JScript elements. In this case
and if the first element on the page is type="VBScript" then all other
elements without type indication will be treated as VBScript sources.
Even more importantly all intrinsic event handlers like onclick="" etc.
will be treated as VBScript sources. Obviously if one has handlers
written in JScript, she gets nothing by syntax errors around.
In fact it is wrong. I was too concentrated on IE (fallasy away - this
is the UA you have to think most of the time during any project). So I
have forgotten the extended features of Gecko-based browsers where full
ECMA 4 supported activated by type="text/javascript;e4x=1" and
JavaScript 1.7 support activated by (!)
type="application/javascript;version=1.7" (!)

I expressed my surprise long ago at mozilla.dev.tech.js-engine
<http://groups.google.com/group/mozilla.dev.tech.js-engine/msg/436ad6cf117ceea2>
and the answer was that text/javascript should work as well. To my
shame I never checked that and my next Firefox 2 just died under
tortures :-) Could anyone confirm that on Firefox 2.x
type="text/javascript;e4x=1;version=1.7"
will activate _both_ ECMA 4 and JavaScript 1.7 ?

In any case it is definitely another occasion when type attribute would
be required.

Jan 18 '07 #10

This discussion thread is closed

Replies have been disabled for this discussion.