One of the most common scripts used on Dynamic HTML pages is the "browser sniffer" or browser detection script. Browser detection scripts look at information that the browser sends to the Web server and determines what browser is viewing the page. Then, depending on what the developer decides, the page may be modified to better suit that specific browser.
While I can think of situations where it might be nice to know exactly which browser and version a customer is using to view my site, for the most part, I don't care. I don't need to get that granular. All I really need to know is if their browser will support the DHTML function that I'll be using on my site. This is called object detection.
Why is Browser Detection Bad?
Here is an example of a simple browser detection script:
var isNav, isIE;
if (parseInt(navigator.appVersion) ]= 6) {
isNav = (navigator.appName == "Netscape");
isIE = (navigator.appName.indexOf("Microsoft") != -1);
}The code says that the variables isNav and isIE should be set with the results of the browser check. There are several problems with it.
- This script only works with browser versions 6.0 and above. But you might have information that you want to use with 5.0 browsers. This is more a factor of this script being a simplistic example, than a failure of browser detection.
- This script assumes that all browsers will have similar version numbers, but Safari 1.0 and Firefox 1.0 are more standards compliant than IE 6, but they have lower version numbers.
- This script relies on browsers feeding accurate information in their "appName" fields. But many browsers would masquerade those fields to fool developers.
- If this script were to block layers pages from Internet Explorer browsers, it would fail when Netscape 6+ browsers used it? Why? Because Netscape 6+ browsers don't support layers, but they would pass this browser check and then be forced to try.
- If a page using this script used a Windows-only function, Netscape 6 on the Macintosh would attempt to display the page and fail.
You might think that the solution would be to create more checks for browsers and get more and more specific in how a browser labels itself. This is the direction that a lot of developers are using. The problem is that they are left with (in some cases) Web pages that have more JavaScript code than they do HTML. Also, every time a new browser or version comes out, the developer has to re-write the JavaScript to make sure that that browser is supported. This can be a lot of work.
Object Detection to the Rescue
Object detection looks at the object or property needed and verifies that it will work in the browser. This has two benefits:
- You don't need to memorize the DOM for every browser you want to support.
- If an object or property has been deprecated in future browsers (like layers in newer versions of Netscape), the browser will ignore the script.
It is common to see object detection within Dynamic HTML Web pages. People use it for image roll-over scripts, testing for the images property:
if (document.images) {
image rollover code...
}This asks the browser if it can recognize the document.images array. If it can, the rollover script executes, otherwise the browser ignores the code.
When you're building DHTML documents, think twice about using that huge browser detection script, and consider looking at the objects that are essential for your code and detecting them.
