Mixing Scripting Languages | WebReference

Mixing Scripting Languages

By Rob Gravelle


During the last few weeks, while building HTML Applications (HTAs), I encountered some snags that have caused me to stop and think more about exactly how browsers interpret markup and scripts. In dealing with the latter, this article will highlight some of the ramifications of mixing scripting languages in your web pages. Although these discussions will be applicable to cross-browser scripting in general, many of the points will be relevant to HTAs as well.

Supported Languages

Some scripting considerations do apply to HTAs because they present content using the Internet Explorer browser. As such, HTAs can be written in any scripting language which will work in Internet Explorer (IE): namely JScript and VBScript. Strictly speaking, JavaScript is NOT supported by IE. Unlike most browsers, Internet Explorer doesn't understand regular JavaScript. Instead it treats any JavaScript as if it was Microsoft's proprietary JScript language and processes it accordingly. That's why so many scripts have to include IE-specific code. Take the following function:

In typical cross-browser fashion, the else if checks for the JScript attachEvent() function. Testing for the existence of a function or attribute has replaced browser sniffing techniques, as the introduction of newer browsers has made that technique unreliable. In either case, the result is functions that are split into two: one part for JavaScript, and the other for JScript. An alternate style is to simply put each script in separate JavaScript and JScript tags. The following page demonstrates how browsers will only run the languages that they support. Hence, Firefox and Opera ignore JScripts and VBScripts, while IE runs all of them:

The Default Scripting Language

At first glance there may seem to be some ambiguity between JScript and JavaScript execution in IE since it recognizes both. However, when faced with two identical functions, IE's answer to the dilemma is to choose the default scripting language. Other browsers work much the same way. Have you ever noticed that you can create a script without a language or type attribute? If not, try it now. Write a simple script and remove the type tag, so that only the bare <SCRIPT> opening tag remains. It will still work in a browser, but IE will evaluate the JScript code while other browsers will use JavaScript. That happens because JScript is the default scripting language in Internet Explorer, while JavaScript is the default for most other browsers. But that isn't the whole story where IE is concerned. It will actually switch to VBScript when there is a script with the language=VBScript or type="text/vbscript" attribute. This presents a potential issue for pages that contain both JScript and VBScripts. Certainly, the practice of always including language and/or type attributes in all your scripts is recommended, but it won't necessarily solve your problems because of intrinsic event handlers.

Intrinsic event handlers are sinks that bind scripting code to document elements. They are triggered when something happens to an element. You can recognize event handlers by their "on" prefix. Some examples include the onload, onunload, onmouseover, onmouseout, and onclick events. Unless specified, all intrinsic event handlers use the default scripting language:

You can see how browsers use their preferred default scripting engine when they are presented with identical functions in different scripts. In the following example, IE will use the JScript function, while other browsers will use JavaScript:

The above code produces the following two alerts; the first in Internet Explorer, the second in Firefox:

Figure 1

Figure 2