Hypermedia Production, Fall 2000: Platform Detection and Handling

There are hundreds of Web browser (client) programs in the world and many different operating systems to run them on--various flavors of Unix and Linux as well as Windows 95/98/NT/2000 and MacOS/OS-X. After five years of intensive development of HTML and related Web technologies, you might think the differences among all these platforms would have diminished... and you'd be WRONG!

Even among the nine most significant browser/platform combinations:

Netscape on Windows	Netscape on MacOS	Netscape on Linux
Internet Explorer on Windows	Internet Explorer on MacOS	Internet Explorer on Linux
AOL Client on Windows	AOL Client on MacOS	AOL Client on Linux(?)

functions vary widely among browsers produced by the same company. This is partly because operating systems and their application programming interfaces (APIs) don't behave consistently, and also because not enough care is taken to coordinate the work of various development groups. Whatever the reason, we're stuck with the results.

Let's face it, folks, designing Web pages to work across all platforms is the stuff of infernal torment. For all the nasty details, see the Mozilla documentation on client detection. It makes the old East German tax code seem elegant by comparison. Say, maybe Al Gore really did invent the Internet!

But happily, we do not have to deal with platform compatibility issues as exhaustively as we would if we worked for some vast dot-com. For our naive academic purposes, we will assume there are only two browsers and two operating systems in the world (recklessly ignoring AOL and foolishly forgetting Linux).

Not that this gets us out of the Bad Place.

II. Using JavaScript to Detect Platform and Client

All major JavaScript-enabled browsers are able to use the navigator object (and yes, this includes Internet Explorer, which is like having a part in your Ford called "the chevy"). As I'll explain, not all browsers can use this object in the same ways, but they will successfuly execute the following code:


document.write(navigator.appName + "<br>");

document.write(navigator.userAgent + "<br>");

document.write(navigator.appVersion);

Here's what that code displays when it is run:

In most cases you would assign one of these properties, let's say appName, to a variable for testing, thus:


1. whassApp = navigator.appName;


2. if(whassApp == "Microsoft Internet Explorer") location="softy.htm";

(I've numbered the lines in this code example and introduced an artificial break because the second line wraps deceptively: there's no carriage return between the if condition and its dependent clause.)

Resetting the value of the location object is equivalent to typing a URL into the location window of the browser or following a hypertext link. If you have content that will only work in one browser or the other, you can use this technique to shunt users in the appropriate direction. I'll describe such a situation below.

First, however, a refinement. Because the contents of navigator.appName and other navigator properties vary from platform to platform (aaagh!), and because the contents of this property may change in the future (if, for instance, Microsoft becomes two separate companies), it's safer not to look for an exact match. Instead you should scan the property value more flexibly, as in this example:


if(whassApp.indexOf("Explorer") > -1) location="softy.htm";

The code above will work even if your Web client calls itself "Macrostiff Cyberspace Agglomerator Deluxe Formerly Known As Explorer In The Good Old Days When We Ruled The World."

The indexOf() method of the string object (navigator.appName is a string) returns a number indicating how far the first character of the target string (in this case "Explorer") lies from the first character of the subject string. You don't need to bother about this number beyond recognizing that it will be zero or greater if the target string occurs within the subject string. If the target string is not found, indexOf() returns -1.

So now you know how to sort the 'Softy sheep from the Gates-hating goats. Alas, you may need to use this technique. Here's why.

III. Plugin Detection

A great deal of popular Web content, such as Quicktime and Director/Flash movies, requires a software supplement called a plugin. Plugin content is introduced through an <OBJECT></OBJECT> container (the method Microsoft prefers), an <EMBED></EMBED> container, or both. In most cases the application you use to develop the content will also generate the necessary code, which is quite dense. This generated code usually includes a pluginspage attribute which automatically connects to Macromedia's site, Apple's site, or wherever, and triggers download if the plugin is not presently installed.

Sometimes, however, Web designers need to bypass this distracting scenario--especially if they're working with impatient or inexperienced audiences such as middle-aged adults. This can be done by using the plugins array of the navigator object. Here's an example:


for(i=0; i < navigator.plugins.length; i++)

	{

		document.write(navigator.plugins[i].name + "<br>");

	}

Here's what this code returns when executed:

If you are viewing this page using Internet Explorer on a Windows system, you'll see an apology instead of useful data. Try hitting this page again in Netscape. Hm. If you happen to be running Explorer on a Macintosh, the script will work properly. Hmmm. This is some of that cross-platform hellishness I mentioned earlier; and it poses a real problem.

If the browser is not MSIE on Windows, you can scan the names of the available plugins. This lets you do a variation on the platform check described above:


1. var plugged = 0;


2. for(i=0; i < navigator.plugins.length; i++)


3.	{


4.		if(navigator.plugins[i].name.indexOf("Boo") > -1) plugged = 1;


5.	}


6. if(plugged == 0) location = "unPlugged.htm";

Once again I've inserted extra line spaces and numbered the lines to make the code more understandable. Delete the numbers if you want to use this script yourself.

This script runs through all the available plugins. If one of them matches a relevant keyword ("Boo" in this example), it sets a test variable from 0 to 1. At the end of the for loop that performs the scan, we examine that test variable. If it's still 0, we know the plugin is missing and branch to a page that does not require the plugin.

But all this happens only if the user has the right combination of browser and operating system. Not an ideal solution. How you deal with this devil's bargain is up to you, but here are some guidelines based on generally accepted design practice.

If your plugins are fairly standard (Quicktime, Shockwave, RealPlayer), just rely on the code generated by whatever application you're using. The automatic download option works more elegantly for Windows than for MacOS, but both platforms do support it.
If you're using an exotic plug-in, set up an entry page that warns users about it, providing a link to a download page. For an instance of this strategy, see Melissa Allen's vikingGurl. (She uses a standard plugin but the example is still useful.)
If you really, really must auto-scan for plugins, first check navigator.appName to see if the browser is Explorer, then check navigator.appVersion or navigator.userAgent to detect Windows. If you find Explorer in Windows, bypass your scan routine because it could return a false negative.

IV. Browser Detection, Style Sheets, and DHTML

If browser detection has only limited usefulness with regard to plugins, it's of more help with some other specialized features: Cascading Style Sheets (CSS) and Dynamic HTML. Netscape browsers earlier than 4.0 did not support CSS, and support in Explorer 3.0 was very limited. If you're using a particular style sheet effect, and if you rely on it heavily, you should check to be sure the browser fits these qualifications.

DHTML is a little more tricky. Technically speaking the concept belongs to Microsoft and Explorer is really the only browser that fully supports its various tricks and treats. However, Netscape browsers will handle some DHTML effects, while even Explorer 5 on the Mac can't if they depend on the Windows-only ActiveX Controls. You'll need to test your pages on all four permutations of our reference browsers: Netscape 4.x on Windows and MacOS, ditto Explorer 5.x. Once you know what does and doesn't work, you can write any necessary scripts for screening.

If you ever need to restrict certain content to later Windows browsers, here's a convenient test condition:


if(document.all)

Microsoft's Document Object Model uses a "collection" called all as its primary object. The if statement above returns true if that object exists and false otherwise.

See the demo page to test these techniques in action and inspect some working scripts.