spacer

Webref WebRef   Sitemap · Experts · Tools · Services · Newsletters · About i.com

home / experts / dhtml / diner / browsvars

DHTML Diner Logo

Developer News
Eclipse Helios Update Brings New PHP Tools
Internet Explorer 9 Ups Standards Support
JBoss Portal 5 Release Easier to Use

DHTML Lab Browser Variables

Everything you always wanted to know about browser detection is covered by Doc JavaScript in his Browser Compatibility column.

On this page, we'll discuss the specific variables that we use here at DHTML Lab, the ones you can find in all our columns.

Browser Version Detection

The JavaScript navigator object has properties that help us to identify the browser vendor, version number and platform. Since different browsers may have different scripts that apply to them, it has been common practice to read the values of the navigator properties, identify the browser being used, set variables accordingly, and later use these variables to execute browser-specific script. For example:
if (navigator.appName == "Microsoft Internet Explorer"
            && parseInt(navigator.appVersion) >= 4) {
    IE4 = true;
}
else {
    IE4 = false;
}    

if (navigator.appName == "Netscape"
            && parseInt(navigator.appVersion) >= 4) {
    NS4 = true;
}
else {
    NS4 = false;
}

if (IE4) {...Explorer-specific code...}

if (NS4) {...Navigator-specific code...}

The above script reads:

If the browser name is "Microsoft Internet Explorer" and if the version number is equal to or greater than 4, then the IE4 variable should store true, otherwise the IE4 variable should store false; if the browser name is "Netscape" and if the version number is equal to or greater than 4, then the NS4 variable should store true, otherwise the NS4 variable should store false.

The Pitfalls of Browser Version Detection

We do not recommend using scripts like the above. Why? Because, we don't care what browser our visitors are using! We only need to know if the scripts we are using are compatible with a browser's rendering machine.

Yes, you say, but are not browser script engines tied to the browser version? Not necessarily!

The following example existed, and probably still exists, on thousands of web pages:

  1. Navigator 3 introduced the Image object, leading to the implementation of image rollovers for navigation on countless sites.
  2. Most of these sites used browser detection similar to the one above to allow access to rollover scripts only for Navigator 3. Explorer 3 did not have the Image object at the time.
  3. Explorer's JavaScript (JScript) engine is external to the browser, and can be updated. JScript 2.0 shipped with Explorer 3.02, and was made available as a free upgrade to older Explorer 3 versions. It included support for the Image object.
  4. Explorer users were still shut out of the rollovers, even though their browser may have supported them. Expanding the script to check for Explorer and a version equal to or greater than 3.02 was an option, but what about 3.0 and 3.01 users that had upgraded?
  5. A point could be made for using the Explorer-specific method, ScriptEngineMajorVersion() to check for JScript version, but it was only implemented in JScript 2.0 and generates errors on JScript 1.0.
  6. Most authors only updated their detection upon page rewrite. Many rollovers still only work for Navigator 3 or better. Even Explorer 4 is shut out!

Using the browser version detection method, the script would have to be:

haveImage = false;

if (navigator.appName == "Microsoft Internet Explorer") {
    if (typeOf(ScriptEngine) + "" != "undefined") {
        se = ScriptEngineMajorVersion();
        if (parseInt(se) >= 2) {
            haveImage = true;
        }
    }
}

if (navigator.appName == "Netscape"
            && parseInt(navigator.appVersion) >= 3) {
    haveImage = true;
}

if (haveImage) {...Image object code...}

Object Detection

If a browser supports the Image object, its document object has an images array to store the image objects. We can therefore check for the existence of this array, without regard for the browser vendor or version:

if (document.images) {
    haveImage = true;
}
else {
    haveImage = false;
}

if (haveImage) {...Image object code...} 

We could even dispense with variable creation and execute script after a direct test on document.images:

if (document.images) {
    ...Image object code...
}

Both of the methods allow access to any browser that supports the Image object. If a new JavaScript-enabled browser were to appear on the scene that also supported Image, then it too would be given access, with no additional code intervention. This possibility is not as far-fetched as it sounds, because the ever-growing-in-popularity Opera browser is just such a case!

Our Variables

In the DHTML Lab, we concern ourselves with DHTML techniques for Explorer 4 and Navigator 4, which have two different document object models. The code we develop addresses these two models, so we identify which browser is being used by which object model it supports. Navigator 4's model is based on the layer concept, and it hosts a document.layers array. The Explorer 4 model contains the document.all collection (array) that reflects all the elements in the document.

These are the only two DHTML models in existence. If a third browser were to develop DHTML support, it would probably base it on one of these two models. For clarity, we use NS4 and IE4 as the variables that represent these models:

In its long, easily understood form, the DHTML variable assignment becomes:

if (document.all) {
    IE4 = true;
}
else {
    IE4 = false;
}

if (document.layers) {
    NS4 = true;
}
else {
    NS4 = false;
}

We can shorten our code, by using the JavaScript "?:" special conditional operator:

condition ? expression1 : expression2

The first expression is returned if the condition evalutaes to true and the second if the condition is false. Applied to our code:

(document.all) ? IE4 = true : IE4 = false;
(document.layers) ? NS4 = true : NS4 = false;

We then shorten it some more by using the operator to assign the variable values:

IE4 = (document.all) ? true : false;
NS4 = (document.layers) ? true : false;

Since true and false can be represented by 1 and 0, our code becomes:

IE4 = (document.all) ? 1 : 0;
NS4 = (document.layers) ? 1 : 0;

Since we are using the operator to assign true/false values depending on the true/false evaluation of the condition, we can simply dispense with the value assignment completely and simply assign the condition to the variable. If the condition is true, then so is the variable and vice-versa:

IE4 = (document.all);
NS4 = (document.layers);

or

IE4 = document.all;
NS4 = document.layers;

Now isn't that a LOT easier, less typing and more elegant than the very first example on this page?

In many cases, the object models overlap and common code can be used. A third variable, ver4, is used to represent a browser that supports either of the two object models:

IE4 = (document.all);
NS4 = (document.layers);
ver4 = (IE4 || NS4);

That is how we arrived at the browser variables used in DHTML Lab.

Exceptions

There are some cases when a browser seems to support an object, but really doesn't! An example is Explorer 4 for the Macintosh. It does not support all the DHTML features that its Windows counterpart does. Much of the DHTML in Explorer for Windows has been developed from operating system features, making it platform-specific. Visual and Transition Filters are an example. In other cases, properties are supported, but not rendered! Element dimension clipping is an example.

When we use code that we know is recognized, but not rendered, we must resort to browser platform detection, to filter out a particular version of a browser. In columns that use clipping, the Hierarchical Menus, for example, we identify Explorer 4 for the Macintosh, to hide code from it:

     IE4 = (document.all);
     NS4 = (document.layers);
    ver4 = (NS4 || IE4); 
   isMac = (navigator.appVersion.indexOf("Mac") != -1);
  isMenu = (NS4 || (IE4 && !isMac));

if (isMenu) {...menu code...}

Unfortunately, if Explorer 4 Macintosh does eventually render these features, we will have to change the variables. But at least we know we tried to be as compatible as possible!



Produced by Peter Belesis and

webref The latest from WebReference.com Browse >
Flashmaps' DynamicLocator: Interactive Maps for Small Areas · Flashmaps' AreaSelector: Interactive Maps for Wide Areas · The DB Mapper: Interactive Street-level Maps of U.S. and Canada
Sitemap · Experts · Tools · Services · Email a Colleague · Contact FREE Newsletters 
 The latest from internet.com
MS Access and MySQL · Cisco AutoQoS: VoIP QoS for Mere Mortals · While VoIP Adoption Explodes in Enterprise, Carrier Spending Lags

All Rights Reserved. Legal Notices.
Created: May 07, 1998
Revised: May 07, 1998

URL: http://www.webreference.com/dhtml/diner/browsvars/