Yes, I imagine you are going round and round. In the realm of client sniffing, beware - there be dragons! Here are some of the issues:
Some browsers, notably Opera, offer the user a chance to spoof the browser's identity as Explorer or several flavors of Mozilla.
Some browser sniffers will test for the presence of a DOM object and assume the browser's identity from that bit of information. This worked OK for a while and for some objects (document.layers, for example, is a sure sign of Netscape 4) but with more recent browsers, object detection gets very complex.
Even if the user agent string tells you that you have a recent AOL browser, with AOL 8, the Windows version is based on Explorer, but the Mac version is based on Netscape. The differences can give you some surprises.
So, the real question is why do you want to detect the browser and version - for what code? Are you actually going to serve a different page to the older browsers?
I personally stopped browser sniffing. It just got too crazy. Instead, I write W3C valid code, check the rendering on a few browsers and then let it go.
A SORT OF ANSWER
Now, for your specific test - if all you care about is that the browser is at least as recent as one of those three, then this should detect that fact for you with relative safety:
Well, I take that back, just a bit.
Testing for getElementById will give you IE5.5 and above (which I assume is really what you want - decent DOM support). However, IE5.5 doesn't offer the fullest DOM1 support, so you should still test your code live in that browser.
Sorry if I've just added to the confusion. It is pretty chaotic. That's why I stopped doing it. Another way out is, if you want to use some particular DOM object in DHTML, test for that object. Then you know your code will work- and you don't need to know the specific browser at all.
[edited by: tedster at 5:41 am (utc) on Oct. 4, 2003]