There has always been confusion on the official MIME type of javascript. While servers mostly seem to use the following Apache rule: AddType application/x-javascript .js authors claim it is text/javascript in the TYPE attribute of the SCRIPT element (if they declare it). That has multiple reasons. First of all, the HTML specification suggests text/javascript and application/x-javascript is not supported by Internet Explorer. Note that IE does not support it only if it is the value of the TYPE attribute, what the server sends does not seem to matter.
And it gets even better. While the HTML camp is happily referring to their .js served as application/x-javascript using text/javascript as value for the TYPE attribute SVG people are using text/ecmascript. And again, this is because the SVG specification suggests it.
Perhaps, in the near future this will all be over when the draft of Scripting Media Types (01) becomes a RFC. Eventually it will specify two media types. (Currently it lists four.) One for javascript and one for ECMAScript. From a theoretical point of view I hope application/javascript and application/ecmascript will survive to the end. However, text/javascript and text/ecmascript are probably more useful with regard to current implementations and specifications.
Staying with text/... might become a must as application/... seems to suggest some people that a file is meant to be opened using a specific application or is generated by a specific server-side application. Other that that I'd go for the latter. Anyway, becoming an RFC does not guarantee adoption - try to find three validating pages on the first page of google's output for any non-webdesign query.
Note that IE does not support it only if it is the value of the TYPE attribute, what the server sends does not seem to matter.
IE is known for not using the MIME type served by the server. It even accepts and parses HTML sent as text/plain.
I didn't read the draft of Scripting Media Types you refer to, but I had read the following: ECMA-Script is the standard that defines the syntax of the scripting language, while Javascript has become the common name refering to the language using this syntax and DOM and other properties defined differently in each browser.
(Javascript was the name for Netscape's implementation of ECMA-Script. Microsoft called it Jscript)
I think we would need a document standardizing Javascript. Some part of it are standards, like ECMA-Script and the DOM, but some really useful properties are completely different accross browsers.
Anyway, even with a standard, we will have to do with Internet Explorer, since a new version won't show up soon. And it's exactly the same thing for the MIME type: whatever will be the standard, we will have to use text/javascript.
Javascript 1.5 is a superset of ECMAScript as far as I know and has nothing to do with the document object model. Although you can use the DOM within it.
Also, both Jscript and Javascript existed before ECMAScript was drafted. (That is why it got the horrible name, to satisfy both Netscape and Microsoft.)
The disadvantage of text/* is the character encoding that is bound to it. application/* might suggest that it is opened by an application Patrys, but that is certainly not the case. Just think of application/xml or even better, application/xhtml+xml.
Javascript 1.5 is a superset of ECMAScript as far as I know and has nothing to do with the document object model. Although you can use the DOM within it.
I'm not a specialist, but I think you're right. What I meant is that you can't do much with ECMAScript alone. You can maybe do some date calculation, but since you can't display it, it is not very useful. To display anything you need to manipulate the document. You can do it either the "old" way, with document.write, or with the DOM. document.write is a method of the object document, which isn't a native ECMAScript object, and I haven't seen this documentated as a standard anywhere. Fortunately, it works both in Javascript and in JScript. But there are other object properties and methods that differs between browsers (e.g. the way to find selected text in a textarea).
(Note that document.write isn't allowed to manipulate XML, which means you can't use it in XHTML served as XML)
I think they should stick to text/* for the following reasons:
The disadvantage of text/* is the character encoding that is bound to it.
Could you please elaborate that?
Staying with text/... might become a must as application/... seems to suggest some people that a file is meant to be opened using a specific application or is generated by a specific server-side application.
I think that explanation isn't logical, because the definition of "application" (in this context) is unclear. A JavaScript/ECMAScript interpreter might also be considered as an "appllication".
text/* MIME types have US-ASCII by default. (It is basically the same reason why you should use application/xml instead of text/xml.
With ECMAScript standardising the language syntax, and the DOM standardising access to the document, we don't really need anything else, do we? OK, a window object, perhaps.
Anne, if I recall correctly, CSS served as text/css inherits the character encoding of the document. Doesn't the same apply for text/javascript? I've had no problems using Swedish letters such as 'Å' or 'ö' in script code. Is that because browsers don't follow the rules about encoding?
Tommy, that is because the CSS specificiations defined such a mechanism. I am not aware of Javascript or ECMAScript specifying any of that.
About the JavaScript naming issues... originally it was called LiveScript, but because Java was really hot during those days it was renamed to JavaScript. And then Microsoft named their implemenation JScript. I'm not sure where ECMAScript comes from, though.
Nicolas, document.write is documented in DOM Level 1 (HTML).