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
<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:
Find a programming school near you
