Should I use a type attribute on script tags?

I have immense respect for Douglas Crockford, but that doesn't mean I can't disagree with him... Douglas has written on a number of occasions that he prefers plain script tags, with no attributes. The argument goes like this:

"This script block uses the language attribute. This was a feature that was introduced by Microsoft in order to support VBScript. Netscape then adopted it to support its own nonstandard deviations. W3C did not adopt the language attribute, favoring instead a type 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."

What he forgets to mention here is that if you care about XHTML compliance, you can't make the economy of the type attribute. I also think it's good practice as we don't know if in the future browsers won't support other scripting languages, even if the default will probably always remain JavaScript (and even if browsers don't support them, we've used our own type in the past for xml-script and handled the parsing ourselves). It's also more expressive.

The second thing that I think is not quite true here is that the MIME type wasn't standardized. MIME types are standardized by IANA (Internet Assigned Numbers Authority). IANA lists both "text/javascript" and "text/ecmascript" as obsolete, pointing to RFC 4329. The valid types are "application/javascript" and "application/ecmascript". All modern JavaScript interpreters being implementations of ECMAScript, it seems like it would be best to use "application/ecmascript".

Except that our good friend IE doesn't recognize them and ignores the script altogether if you use them. So once again, thanks to one more non-standard behavior of IE, we can't afford to follow the standard.

So to sum this up, if you don't care about XHTML compliance or expressiveness of your markup, it's probably safe to use a plain script tag. If you do, you should use "text/javascript" until IE gets its act together (if that ever happens).


  • I don't know about going forwards but going backwards I can vouch for the fact that for IE 5.5 I was better off leaving it off. We had a lot of weird script engine issues that were only happening in code where we had the attribute - took it out and magically the problem was solved.

  • @Dave : The futur of the internet is not based on IE 5.5 -_-

  • Brett, you're right, I'm an idiot and I've updated the post.

  • You can violate RFC 4329 or you can violate XHTML 1.0 or you can fail on some browsers. You must choose one. I find it is best to ignore XHTML because it isn't going to happen anyway. We are stuck with HTML.

  • "in the future browsers won't support other scripting languages"

    On one hand, I understand why we want to think about what future browsers will/won't support. A lack of that kind of thinking got us, the web developer community, into a mess 5-7 years ago.

    But there's lot of things, plugins and what not, that browsers might not support in the future. Should we ignore all of those things now? No.

    The biggest problem I had with Crockfords statement is that he didn't present any negative effects of using the "type" attribute. He didn't have an example of something breaking or not working because the tag had a "type" declared. I don't see any reason to not use the type attribute.

  • Douglas: all that's true, but not everyone may have the luxury of ignoring XHTML. Many administrations have this as a requirement. Also, even if some browsers *cough* IE *cough* don't support XHTML, it's still very useful in situations where you need the markup to be a dialect of XML for whatever reason.
    For me, violating RFC 4329 is by far the least of those three evils: (almost) no one can afford to fail on IE, many people can't afford to ignore XHTML and there is no big disadvantage in violating RFC 4329.
    Just trying to present people with the options and what they imply.
    Thanks for the comment!

  • Hi,
    I hav a situation that i need to open a file in specific program... For example i have a Text file(Notepad) and Onclicking,it must get opened in Notepad... How do i do that in ASP.Net using C#..

    and also i need to download multiple file in ASP.Net... If u have any articles or codes regarding this send to me...
    Im expecting ur reply...


  • Shanmuganathan: you're terribly off-topic ;)
    Please send me mail using the contact form on this blog and I'll give you an answer offline.

  • How to create aspx pages Dynamically?

  • PKINTAL: this is off-topic. Please send me mail through the contact form of this blog and I'll give you an answer offline.

  • But what about the JavaScript version number?

    Isn't there contradictory syntax between JS 1.0 and 1.2 for example -- equality operators? strict typing? -- and it's the version number in the script tag is the only way to switch between the modes?

    Is JavaScript syntax now frozen in 1996 -- you can only use JS v.1.0? Or do modern browsers inherently use a later JS version -- so your current code will break in older browsers?

  • Mike: unfortunately there isn't much for JS version mangement. Prettt much everyone is targetting EcmaScript 3 at this point (which all modern browsers implement), but there's still a debate going on on how this is going to work in the future. This is going to have to be solved before the next version of EcmaScript is out, whatever that is.
    Currently, There are differences between browsers (bugs and additional features). For bugs, people just work around them, sometimes with ugly browser detection code, and for additional features, people either don't use them or use capability detection (checking if a method exists before using it).
    But differences between implementations of the EcmaScript are nothing when compared with the nightmare that is DOM quirks anyway.

Comments have been disabled for this content.