TYPE attribute of the
SCRIPT element (if they declare it). That has multiple reasons. First of all, the HTML specification suggests
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
TYPE attribute SVG people are using
text/ecmascript. And again, this is because the SVG specification suggests it.
application/ecmascript will survive to the end. However,
text/ecmascript are probably more useful with regard to current implementations and specifications.
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
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
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,
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.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.
text/* MIME types have US-ASCII by default. (It is basically the same reason why you should use
application/xml instead of
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
document.write is documented in DOM Level 1 (HTML).