Browser Detection... and then some

by Aaron Bertrand

We all know that to make a successful and attractive web site, we must strictly adhere to HTML 3.2 standards, avoiding all temptations to use any browser- or platform-specific tags and features. We have to find innovative ways to present browser-specific content, yet still have it degrade gracefully for everyone else.

Yeah, right. And 640k ought to be enough for anybody.

For the rest of us, we have to find innovative ways to present browser-specific content, yet still have it degrade gracefully for everyone else. This can be relatively straightforward for individual elements, such as ActiveX controls, cascading style sheets and even Java applets. But what if you want to present a certain paragraph only to IE4 users? or only let Netscape users see the contents of a specific <div> element? or make your body text 10pt for a Mac, and 9pt for a PC?

There is a way to do these things, without using COM objects, a database, or 200 tedious client-side document.write commands. All you need is a little familiarity with the user agent string of the browser you wish to target.

Let's start with getting at that string in the first place. It is available in the server variable "http_user_agent" and can be accessed as follows (I convert this variable to lower case, in order to prevent ambiguity):

    myUA = request.servervariables("http_user_agent")
    ua = lcase(myUA)
This code will produce a string similar to one of the following:
  • mozilla/4.0 (compatible; msie 4.01; windows nt)
  • mozilla/4.5 [en] (win98; i)

Be aware that there are literally thousands of unique user agent strings. Thankfully, the ones you will likely be most concerned with share common characteristics. Also, depending on the purpose of your discrimination, most can be grouped into similar categories.

Let's take DHTML for example. Say you want to have a headline that, when clicked on, presents an "abstract" and a link to more information (instead of linking the user right away). The code would look something like this:

    <a href="somewhere.asp"
     onClick="myDiv.style.display=''">This is a link</a>
    <div style="display:none" id="myDiv"><br>This is an in-depth description of the link, as well as <a href="#top">an actual link</a>.</div>

In IE3 and NN3, the description and link will always be visible, and in Netscape 4 it will never be visible. In most cases the code above will generate a scripting error as well, which is not pretty. However, in IE4 or greater, the description will be hidden until the user clicks on the headline. Wouldn't it be nice if you had the ability to regulate that code, and ONLY insert the extra DHTML snippets for IE4 and IE5?

Here's what you can do, based on the code above. Since all IE4+ user agent strings (including AOL and NeoPlanet versions) are remarkably similar, you can search for "msie 4" or "msie 5" in the above strings. If this string is found, you know that your visitor is using IE4 or better, and so it is safe to include your DHTML code. For example:

    myUA = request.servervariables("http_user_agent")
    ua = lcase(myUA)
    ie4 = instr(ua,"msie 4")
    ie5 = instr(ua,"msie 5")
    if ie4>0 or ie5>0 then
    ' You can include DHTML code:
    <a href="somewhere.asp"
     onClick="myDiv.style.display=''">This is a link</a>
    <div style="display:none" id="myDiv"><br>This
     is an in-depth description of the link, as well as
     <a href="#top">an actual link</a>.</div>
    ' Don't include DHTML code:
    <a href="somewhere.asp">This is a link</a><br>This
     is an in-depth description of the link.
    <% end if %>

Here is that code in action (if you view source of this document, do a search for "sample" -- depending on the browser you are using, you will see that the appropriate source code has been returned):

This is a link
This is an in-depth description of the link.

If you find that certain script elements you use only work on certain platforms (e.g. Win32), you can add extra search elements into your discriminatory code, searching for key elements like "x11", "mac", "win95", "win98", or "winnt" -- the possibilities for this kind of browser detection are really only limited by your imagination and creativity. I use it almost religiously when writing any ASP application... from scripting functions, to adding CSS support, to deciding whether or not to tell people they're using an outdated browser (which you are not).

If manual browser detection isn't for you, I strongly recommend you take a look at cyScape's BrowserHawk before you resign yourself to using BrowsCap. Version 2.0, released 01/21/99, is a very powerful server-side component which makes browser detection a breeze and, unlike BrowsCap, maintains itself as new browser versions are released. If you are using BrowsCap, however, make sure you keep it up to date: Juan T. Llibre keeps a browscap.ini file up to date here.


This article was originally published on Apr 6, 1999
Page 1 of 1

Thanks for your registration, follow us on our social networks to keep up-to-date