Professional JavaScript | 41 | WebReference

Professional JavaScript | 41

To page 1To page 2current page

Professional JavaScript

Detecting Versions
<SCRIPT LANGUAGE="JavaScript">var v = 1.0</SCRIPT>
<SCRIPT LANGUAGE="JavaScript1.1">v = 1.1</SCRIPT>
<SCRIPT LANGUAGE="JavaScript1.2">v = 1.2</SCRIPT>
<SCRIPT LANGUAGE="JavaScript1.3">v = 1.3</SCRIPT>
<SCRIPT LANGUAGE="JavaScript1.4">v = 1.4</SCRIPT>

This script shows a simple way of detecting JavaScript versions- at the end, 'v' contains the highest version supported. If a rough guide is all you need it should suffice. Unfortunately, all it really tests is the tag attribute. JavaScript for Internet Explorer 3.0 on the PC and Macintosh are subtly different in features. JavaScript 1.1 is "supported" in Internet Explorer 3.0 with Jscript 2.0, but doesn't support all the features in Netscape's 1.1 implementation. Bugs and beta releases further cloud the water.

There are other ways of gathering information about the browser and JavaScript.

The navigator.userAgent property contains a unique string describing the browser version, brand and platform. Although it doesn't contain the JavaScript language version, it can sometimes be deduced. For example, Netscape 2.02 has the string 'Mozilla/2.02 (Win95;I)' for the Windows-95 32-bit version and that version is known to support only JavaScript 1.0.

Via Netscape's LiveConnect and Java, the operating system and its version can be detected, provided Java support is enabled. This script will report 'Windows 95-4.0-Pentium' for Netscape Navigator 3.03 32-bit for the PC we used to test with:

var str = '';
str += java.lang.System.getProperty('');
str += java.lang.System.getProperty('os.version');
str += java.lang.System.getProperty('os.arch');

This script works for Netscape 3.0 and 4.0 browsers.

A warning - watch out for the processor specific information in the above two example strings. 'I' and 'Pentium' may well vary if your computer doesn't have a genuine Pentium I processor, as most new computers don't now. It's safer to just test using the operating system version.

For Internet Explorer, the JavaScript version is accessible directly via special native functions. However, this requires at least JScript 2.0, or else the script will fail with no ability to trap errors. An example:

var str = '';
str += ' ' + ScriptEngineMajorVersion();
str += ' ' + ScriptEngineMinorVersion();
str += ' ' + ScriptEngineBuildVersion();

Common output for this example would be '2 0 1125'.

As a last resort you can detect the JavaScript version by testing in the script for a specific feature or bug that you might know is unique to a given version.

Supporting Several Versions

Once the JavaScript version is known, there are three main strategies available: separate pages, alternate script blocks, and object guarding. Separate pages means creating separate HTML+JavaScript documents for each language version, and displaying the appropriate one. Alternative script blocks means providing <SCRIPT> blocks in the HTML for each version and using an if test at the start of each so that only the 'right' one does anything. Object guarding is perhaps the most flexible method. We guard the object we're not sure about with a test and only use it if the test passes. It is illustrated in this example:

... more HTML and JavaScript ...
if ( top.images ) { change_image(); }

The top.images property is problematic in some browsers, so calling change_image() won't always work. In this example, by testing the property against null, nothing is done if it doesn't exist. This allows feature-by-feature compatibility without regard to versions, but it also means using a lot of extra ifs if you use many non-portable features.

Which features should you watch out for? The Appendices extensively list the objects available, and specific well-known problems are discussed in the subject areas throughout this book where they are most often used - for example, read about images in the Multimedia and Plugins chapter.

Alas, nothing will guard you against bugs. Netscape is good enough to publish theirs publicly on the Web site (see bugzilla, the bug database), and there's Microsoft's knowledge base if you're patient with the response from, but even so, you're pretty much on your own if you find a bug in a browser. The public USENET JavaScript newsgroup comp.lang.javascript always contains a few battle-weary veterans of browser bugs and compatibility issues, and they might help you if your question hasn't been asked a million, million, million times before.


This chapter has described all the browser cracks and crevices into which JavaScript scripts can be stuffed.

With Internet Explorer and Netscape Navigator/Communicator having the lion's share of the Web market, understanding where your client-side JavaScript can be put is a critical hurdle that needs jumping before you can do anything meaningful. The bottom line is, most JavaScript goes inside the HTML page.

However, we've also given a nod briefly to other browser possibilities where JavaScript applies. There are many other browsers, generally more humble and generally more obscure where you can expect your JavaScript to run correctly if it's simple. Beyond personal computers, set-top boxes and even mobile phones allow JavaScript or JavaScript-like scripting options in browsers.

For the rest of this book, we'll be concentrating on the JavaScript development environment for mainstream computing uses only. In particular, the next group of chapters will explore in detail the uses and abuses of JavaScript in the normal Web browser environment.

To page 1To page 2current page

Created: April 23, 2001
Revised: April 23, 2001