An important practice when doing cross-browser, cross-platform pages and DHTML development involves the ability to determine the capabilities of the browser which loads your web page.
As a web author, you understandably want to avoid script errors and page layout problems and you may want to ensure your scripts reach as wide an audience as possible.
There are 2 known approaches for such goals: the browser identification approach (also known as userAgent string detection and often referred as “browser sniffing”) and the Object/Feature support detection approach.
The browser identification approach is now known to be complicated, unreliable and difficult to maintain.
Browser identification approach: not best, nor reliable approach
This approach, still commonly used nowadays, attempts to identify the browser and makes the web author at design time decide what that implies in terms of capabilities of the visiting browser. Such approach is fraught with problems and difficulties. It requires from the web author to have knowledge of the capabilities of all current browsers that may visit the page and then to code appropriately for these. It requires from the web author to make assumptions about what will happen with future browsers or to decide to provide future browsers a safe fallback service. It assumes that web authors are able to correctly identify browsers and browser versions in the first place… which is far from being a reliable and easy task to achieve.
The browser identification approach relies on functions that check the browser type string value and browser version string value and that search for certain characters or sub-strings in the navigator.userAgent property string.
Once “detected”, the web author then uses different functions (aka code branching) or points the user to different pages (aka site branching) or web content. Site branching can be particularly dangerous as people may enter a page through a link, bookmark, search engine or cache with a “wrong” browser.
Another major problem with this approach is that the browser identity can be “spoofed” because, in many modern browsers, the navigator.appVersion and navigator.userAgent string properties are user configurable strings. For example,
- Firefox 1.x users and users of any/all Mozilla-based browsers can customize the “general.useragent.*” string properties to any value.
- Opera 6+ allows users to set the browser identification string via a menu
- Internet Explorer uses the Windows registry
- Safari, Konqueror and Icab browsers can mask their browser identity under Internet Explorer or Netscape labels
A user or browser distributor can put what they want in the navigator.userAgent string and this may trick your code into executing a “wrong” block of code. Moreover, there are many cases where even the accurately-identified browser does not perform as it is reputed/expected to.
Using Object/Feature support detection approach: best and overall most reliable
When you use object/feature support detection, you only implement those features whose support you have first tested and verified on the visiting browser. This method has the advantage of not requiring you to test for anything except whether the particular features you code are supported in the visiting browser.
So, instead of needing to know which browsers and browser versions support a particular DOM method (or DOM attribute or DOM feature), you can verify the support for that particular method in the visiting browser. With this approach, you ensure that all browsers — including future releases and browsers whose userAgent strings you do not know about — will continue working with your code.
Change The Way You Do Business Online – Request a Consultation 
For information, email info@cybergenica.com or call our customer hotline at 727.674.5681 from 8:00am-6:00pm EST.