Occasionally browsers have bugs and, as a web developer, you want to write code that handles the bugs. For bugs, it may be necessary to detect the client's browser, version, and platform. The information comes from the Navigator Object. There is no standard for the data, and some of the fields will surprise you. Above is what you're using and below is a table of all the navigator properties and values for this browser.

The code used here reports versions both as strings and as numbers. When using numbers the version is reported as a decimal and any third part is stored separately. See the discussion Below for details.

The following table shows all the properties, whether Netscape or IE support the property and what the browser you're using does. You can load this page into a browser to check that data it reports to help resolve issues.

Undefined means your browser's Navigator object does not have that property—the ultimate non-support. Any other value or blank means your browser's Navigator object has the property; although, the value may be unhelpful.

Navigator properties and values for your browser (All = Netscape & IE from ver 4)
Property Browser Value

   Discussion on browser identification

Other browsers were not considered in the table above (the browser column). They should be tested particularly if you use properties not used by the browser detection code, available on the next page.

The code for browser detection does test for more browsers than IE and Netscape. And, while there is only the one heading to demonstrate the code, it does a pretty good job. The code is free to take and use. Please let me know if you encounter problems or have improvements.

Browser sniffing should not be the first approach to writing cross browser code. Ordinarily, code should test for the existence of an object, property, or method when branching to handle different browsers and not rely on identifying the browser. For example:

        if (document.getElementById){
                code using getElementById(id)
        }
        else if (document.all) {
                code using IE's document.all[id]
        }

Browser sniffing comes into use when property tests return incorrect results or cannot be used. For example a browser reports a property, but the value is known to be incorrect, or there is a rendering bug that is not dependent on the existance of a property.

You will be misled in some cases if your code assumes functionality can be determined by the browser identification. Capabilities are added or removed, other browsers incorporate features from leading browsers, and many identify themselves as another brand. The last issue is to get around sites short changing browsers because the developers use browser identification to determine available features. Test for the feature if at all possible.

The reverse issue also exists. The presence of an object, property, or method should not be used to identify the browser, and, therefore, the availability of an other feature. Again, other browsers may have (or not have) the feature in question or the browser may have been changed adding or removing an object. Your code will not handle these situations and will require more maintenance to stay current. When testing for a property all you learn is if the property (method or object) exists.

So why would you test for the browser and maybe the version? Use browser detection when it is determined that property detection does not report correct information for a particular browser or property detection is not available perhaps to adjust the CSS.

   Browser versions

For reasons similar to the above discussion, I prefer to use numeric browser versions. There are many examples of browser sniffing code that sets boolean flags for every brand and version of interest. However, that approach makes it difficult to write code that will handle future changes and that is simple. By using numeric values, the code can test less than or greater than as well as equal to. Now any version after the bug is fixed, including future versions, will pass the test or any version before the bug was fixed will be handle appropriately.

This plan is good until browsers use version numbering schemes that don't convert directly to numeric data. For example: Mozilla's 1.7.3 scheme. To handle that, versions are convert to a number with 1 decimal point. The third number in the sequence, which is rarely helpful, is stored in a separate field. Firefox released a version 0.10 which is greater than 0.9, but that is not the way it would come out in a numeric comparison of decimals. To guard against that situation, the second version number is converted to a 2 digit number. The results for our Mozilla example is 1.07 and 3 in a subversion field. While it looks off when talking about version 1.7.3 to see 1.07, knowing the pattern allows correct comparisons.