My understanding is that mime types are set by the web server. Why do we add the type="text/javascript
or type="text/css"
attribute? Isn't this a useless and ignored attribute?
views:
366answers:
4Because, at least in HTML 4.01 and XHTML 1(.1), the type
attribute for <script>
elements is required.
In HTML 5, type
is no longer required.
In fact, while you should use text/javascript
in your HTML source, many servers will send the file with Content-type: application/javascript
. Read more about these MIME types in RFC 4329.
Notice the difference between RFC 4329, that marked text/javascript
as obsolete and recommending the use of application/javascript
, and the reality in which some browsers freak out on <script>
elements containing type="application/javascript"
(in HTML source, not the HTTP Content-type header of the file that gets send). Recently, there was a discussion on the WHATWG mailing list about this discrepancy (HTML 5's type
defaults to text/javascript
), read these messages with subject Will you consider about RFC 4329?
type="text/javascript"
This attribute is optional. Since Netscape 2, the default programming language in all browsers has been JavaScript. In XHTML, this attribute is required and unnecessary. In HTML, it is better to leave it out. The browser knows what to do.
W3C did not adopt the
language
attribute, favoring instead atype
attribute which takes a MIME type. Unfortunately, the MIME type was not standardized, so it is sometimes"text/javascript"
or"application/ecmascript"
or something else. Fortunately, all browsers will always choose JavaScript as the default programming language, so it is always best to simply write<script>
. It is smallest, and it works on the most browsers.
For entertainment purposes only, I tried out the following five scripts
<script type="application/ecmascript">alert("1");</script>
<script type="text/javascript">alert("2");</script>
<script type="baloney">alert("3");</script>
<script type="">alert("4");</script>
<script >alert("5");</script>
On Chrome, all but script 3 (type="baloney"
) worked. IE8 did not run script 1 (type="application/ecmascript"
) or script 3. Based on my non-extensive sample of two browsers, it looks like you can safely ignore the type
attribute, but that it you use it you better use a legal (browser dependent) value.
It allows browsers to determine if they can handle the scripting/style language before making a request for the script or stylesheet (or, in the case of embedded script/style, identify which language is being used).
This would be much more important if there had been more competition among languages in browser space, but VBScript never made it beyond IE and PerlScript never made it beyond an IE specific plugin while JSSS was pretty rubbish to begin with.
The draft of HTML5 makes the attribute optional.
Boris Zbarsky (Mozilla), who probably knows more about the innards of Gecko than anyone else, provided at http://lists.w3.org/Archives/Public/public-html/2009Apr/0195.html the pseudocode repeated below to describe what Gecko based browsers do:
if (@type not set or empty) {
if (@language not set or empty) {
// Treat as default script language; what this is depends on the
// content-script-type HTTP header or equivalent META tag
} else {
if (@language is one of "javascript", "livescript", "mocha",
"javascript1.0", "javascript1.1",
"javascript1.2", "javascript1.3",
"javascript1.4", "javascript1.5",
"javascript1.6", "javascript1.7",
"javascript1.8") {
// Treat as javascript
} else {
// Treat as unknown script language; do not execute
}
}
} else {
if (@type is one of "text/javascript", "text/ecmascript",
"application/javascript",
"application/ecmascript",
"application/x-javascript") {
// Treat as javascript
} else {
// Treat as specified (e.g. if pyxpcom is installed and
// python script is allowed in this context and the type
// is one that the python runtime claims to handle, use that).
// If we don't have a runtime for this type, do not execute.
}
}