Tutorial 16: Client-Side Scripting 101
|
| ||||
| ||||
|
|
Specifying the scripting language
You should always specify both the MIME content type of the script and the language the script is in. Although the LANGUAGE attribute is deprecated, you should use it because older browsers do not recognize the TYPE attribute.
The proper value for the TYPE attribute is a bit of a thorny issue. The Internet Assigned Numbers Authority (IANA) has not assigned any media types for JavaScript (or any other of the popular scripting languages, for that matter). Normally, this would mean that you would use an experimental media type by prefixing the string x- to the type. Indeed, the media type most commonly used to describe JavaScript is application/x-javascript. There are two problems with this, however. First of all, the HTML 4.0 Specification recommends, as examples, that the content types text/javascript, text/vbscript and text/tcl be used for the JavaScript, VBScript and Tcl languages. This is obviously wrong, since none of these types have been registered with IANA. This would not really be a problem if it wasn't for a bug in Internet Explorer 4.0 and later versions. These browsers will only run scripts that have one of the following media types: text/javascript, text/jscript or text/ecmascript for JavaScript, and text/vbscript or text/vbs for VBScript. This does force us to use one of the above, and my preference amongst these would be text/ecmascript, as it covers all scripting languages that conform to ECMA-262 (which includes the latest versions of both JavaScript and JScript).
So, for example, if you want to insert a script that is located at http://www.acme.com/scripts/foo.js, you could use something like the following:
The values accepted by the LANGUAGE attribute are mostly browser-dependant. The purpose of both the LANGUAGE and TYPE attributes are to allow browsers that don't support a particular scripting language to ignore the particular script. So, for instance, if a browser doesn't grok the "FooScript" language, it would ignore the following script:
<SCRIPT TYPE="application/x-fooscript" LANGUAGE="FooScript" SRC="http://www.acme.com/scripts/bar.fs" > </SCRIPT>
Traditionally, most JavaScript-capable browsers also understand a version number appended to the language name in the LANGUAGE attribute, for instance, something like the following:
<SCRIPT TYPE="text/ecmascript" LANGUAGE="JavaScript1.2" SRC="http://www.acme.com/scripts/foo.js" > </SCRIPT> <SCRIPT TYPE="text/jscript" LANGUAGE="JScript3.0" SRC="http://www.acme.com/scripts/bar.js" > </SCRIPT>
Presumably, a browser that understands JavaScript, version 1.2, will process the first script, and a browser that understands JScript (Microsoft's semi-compatible version of JavaScript), version 3.0, will process the second script.
In practice, this is a mess. Older browsers didn't even process the LANGUAGE attribute and just blindly executed all scripts as JavaScript, while various browser makers set up their browsers so that they run scripts with LANGUAGE attributes that are not really compatible. The reason is that browser makers are anxious to have their browsers run every script, regardless of whether they can, and are not willing to let someone as puny as an author decide that their script won't run in their browser.
Generally speaking, using the LANGUAGE attribute to decide whether or not a browser can run a script is a bit of a bad idea. The best solution I would recommend is to specify the language only (no version number) in the LANGUAGE attribute and the appropriate MIME content type in the TYPE attribute. If there is a question of compatibility between different versions of the scripting language, what you should do is test capabilities (not version numbers!) of the scripting language within your script. An excellent example of how to do this in JavaScript is given by Peter Belesis in WebReference.com's Dynamic HTML Lab, along with an explanation of why checking for a browser version number is a bad idea.
