As good as ASP.NET’s adaptive rendering is, I sometimes find myself needing to do some fairly substantial client-side scripting. I used to sniff browsers, but that was getting tedious, and most common scripts are written upside down anyway.
The best method I’ve seen is to use ‘object sniffing’–testing browsers for support of different objects and methods. This saves a considerable amount of time, since all browsers will fall into 3-4 categories of object support, and you don’t have to parse out a zillion different browser types and subtypes and still run the risk of excluding one that may work on your site.
My guide was http://developer.apple.com/internet/webcontent/objectdetection.html. The article is a couple of years old, but it’s still useful to me today.
The pace of new browser releases may be slower than it was in the early days, but developers must still confront a bemusing array of browser versions and brands that support some JavaScript features but not others. To combat the problem, scripters commonly provide two or more code branches so that a browser follows an execution path containing statements that it supports. Browser sniffing — the task of inspecting
navigatorobject properties for version information — has become largely unmanageable given the browser version permutations available today. This article presents details on an alternative solution — object detection — that frees JavaScript developers from most of this versioning mess.
I haven’t played around with custom server controls, so I don’t know how applicable this is for that purpose.