Forgot to mention this here. Scripting Media Types registers the following MIME types for JavaScript (and ECMAScript):
text/javascript (obsolete)
application/javascript
text/ecmascript (obsolete)
application/ecmascript
Using the suggested ones inside the type attribute will cause Internet Explorer not to use the script, but you can safely use them server-side thanks to browsers ignoring that completely. (Previously: 1 and 2.) All made possible by the The Björn Höhrmann Project. Thanks!
So basically, we're supposed to use application/javascript, but instead we need to continue to use the text/javascript for ie6.
.... Posh.
How can the text/ ones be found obsolete (and I quote) "because they've been found to be problematic", when they're the only ones that actually work consistently?
Gotta love the mimetype wars...
Dustin, didn’t I say you could use the new media type? James, yeah, I don’t know about that. I personally think we should just make text/javascript the one to be used (same for text/xml) and solve the issues it has in some revision. Fortunately you can unobsolete media type registrations so that should be doable at some point.
I think that application/javascript makes more sense overall. However, as with any MIME type it will probably never be adopted fully, thanks to IE and such.
Note that (AFAIK) Mozilla-based UAs treat text/javascript, application/javascript, and text/ecmascript identically, but application/ecmascript more strictly than the others.
I'm all for serving as application/javascript and using type="application/javascript".
Nothing needs to change with the RFC IMO. If you need to use the obsolete types for compatibility, that's fine. Obsolete doesn't necessarily mean invalid.
How can the text/ ones be found obsolete (and I quote) “because they’ve been found to be problematic”, when they’re the only ones that actually work consistently?
This comments fails to make sense on several levels. The new MIME types were introduced exactly because the text/* ones don’t work well. Of course the new ones don’t work consistently yet – just how ever could they, when they’re new and not yet widely supported? And just because the old ones work consistently for some value of “work” does not mean they’re not problematic, either, does it?
Aristotle: It'd just be nice to have the new ones working first before the old ones are thrown out.
Just wondering if you could elaborate on using scripts server-side... I tried adding text/x-javascript for .js files in my .htaccess file, but IE still didn't recognize it.
I figured out what the problem was (in case anyone else is interested). In addition to serving .js files as text/x-javascript, I had to leave off the .js extension when referencing the file. Ex: <script type="application/javascript" src="/scripts/my-script">
I am still serving JSON and/or Javascript code with
Content-Type: application/x-javascript
from PHP, but haven't seen any mention about it here.
Should I change it ? I believe it has never failed me...
In HTML embedded scripts I am still forced to use "text/javascript" since that is the only cross-browser solution.
This comments fails to make sense on several levels. The new MIME types were introduced exactly because the text/* ones don’t work well. Of course the new ones don’t work consistently yet – just how ever could they, when they’re new and not yet widely supported? And just because the old ones work consistently for some value of “work” does not mean they’re not problematic, either, does it?
Well what then are the problems with the text/javascript mimetype specifically or the text/* mimetypes in general? In the latter case, what problems justify throwing out the baby with the bathwater?
RFC 2046 states that text media types are for textual information [for which] no special software is required to get the full meaning of the text
whereas application media types are for information to be processed by an application.
It seems quite clear to me that JavaScript and ECMAScript are meant to be processed by an application as you can't expect your average website visitor to understand the full meaning of your skillfully crafted DOM manipulations without special software (e.g. a browser's scripting engine) processing them.
Furthermore, data with an application media type can pose security problems which must be understood by implementors
and this can certainly be an issue with these scripting languages.
According to Google Doctype, Internet Explorer will pretty much ignore HTTP MIME types altogether, and will even interpret HTML sent as image/jpeg. I know it will interpret HTML sent as text/plain. Yet another case of Microsoft trying too hard to be clever, and ending up being a pain.
And I've just tried the test page you linked to, and even Firefox accepted the script with the dodgy MIME type, which surprises me.
JSON should, I think, be sent as application/json. It is, really, a markup for structured information (like XML or LISP), rather than a scripting language, so it shouldn't be sent as javascript. (Scan down through those comments for the mention of Saddam: it's interesting.)
TRiG.
Your comments are awkwardly restrictive. I had a URL with unencoded ampersands, and was given the unhelpful message "XML parsing error". I encoded them, and it worked fine in the preview, but refused to post. So I gave up and just posted the link to the Web Sniffer front page, instead of to the result for your javascript with the odd MIME type.
TRiG.