Tales from the Evil Empire

Bertrand Le Roy's blog

News


Bertrand Le Roy

BoudinFatal's Gamercard

Tales from the Evil Empire - Blogged

Blogs I read

My other stuff

Archives

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).

Comments

Dave said:

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.

# September 17, 2007 5:04 PM

Yves said:

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

# September 18, 2007 7:28 AM

Bertrand Le Roy said:

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

# September 18, 2007 12:49 PM

Douglas Crockford said:

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.

# September 18, 2007 4:01 PM

Scott said:

"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.

# September 18, 2007 4:29 PM

Bertrand Le Roy said:

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!

# September 18, 2007 5:36 PM

Shanmuganathan said:

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...

Regards,

Shanmuganathan

# September 19, 2007 5:35 AM

Bertrand Le Roy said:

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.

# September 19, 2007 1:47 PM

PKINTAL said:

How to create aspx pages Dynamically?

# September 21, 2007 6:50 AM

Bertrand Le Roy said:

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

# September 21, 2007 12:33 PM

mike said:

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?

# November 25, 2007 7:09 PM

Bertrand Le Roy said:

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.

# November 26, 2007 12:18 PM