Browser Object

The code here is a lightweight object that I use on my big sites to let me access client side all the main browser settings for the current user. I include it globally on all pages and its one of the first pieces of code that runs setting up lots of useful properties such as:Browser Name, Version, Operating System, Script Support, Flash Support, Rendering Engine. An example is below:

Your Browser Details are:

Include a reference to the script in your page which you can download here.

Then just reference the properties you wish to check as and when you need them:

Browser.name //get name of browser
Browser.gecko //whether browser uses the gecko rendering engine
Browser.flashEnabled //Browser supports flash
Browser.ie //Browser is Internet Explorer

And many more useful properties that detail the users browser settings. N.B I have a property called Browser.AJAXEnabled that will show up as undefined on this page. In my system I set this value on the first function call that requires use of an XMLHTTP object. This function is not included in this script but it would be pretty simple to tie it into your own custon code. If the majority of your pages don't make use of AJAX calls then there is little point in testing for it along with the other browser tests this object does on every page load.

To output all the current settings for the browser object call the Settings() method which will loop through all properties appending them to a string for display purposes e.g:

document.getElementById("BrowserSettings").innerHTML = Browser.Settings();

We have all heard the mantra that browser sniffing is supposed to be evil and that object detection should be used instead wherever possible. In the old days people used to do a check for document.all and document.layers and then branch on the assumption that a browser was either IE or Netscape. Obviously there are more types of browser than those two and browser features and object support change so much its much safer to check the object you are working with first to see if its supported before attempting to use it. This way you are not assuming anything and if a browser changes its support for the object in question you will not be caught out and have to rewrite all your code.

However there are still many instances when you have to branch on browser type or version to implement cross browser code and trying to use an object detection just for the sake of not browser sniffing can be just as bad as doing it the other way round. I think some people see it as an ideological divide between the right and wrong way of doing things when in reality every tool has a use its just a case of knowing the right time to use the tool. In the majority of cases if you want to call a method on an object you should test for the objects existance first but there are certain cases where an object check is not possible or quirky browser issues that mean knowing the users browser is helpful to using the right function call.

Some examples of these quirks I have found where the knowledge of the browser is required are:

The EOLAS patent issue with Flash and IE. As IE was the only browser that suffered the issue any fix was applied to that browser alone.
Memory leakage in IE due to its event model. I use an unload handler to remove all listeners attached in Windows versions of IE. Some people might test for attachEvent but Opera supports this and IE may in the future decide to support the DOM 2 addEventListener. Also just checking for attachEvent does not take account whether the operating system is Windows or not.
In LazyLoader and DOMReady functions older versions of Safari and Opera don't support the standard script.onload, script.onreadystatechange or document.DOMContentLoaded events which you cannot check for therefore with a test like if(document.DOMContentLoaded) timers are used instead.
To reference an Iframes window in most browsers you can use iframe.contentWindow however Opera returns the window when accessing iframe.contentDocument. Therefore you need to know whether the browser is Opera to make sure the correct pointer is returned.

So you can see from these examples there are some legitimate reasons for using browser detection and we shouldn't throw the baby out with the bathwater in this regards. Most frameworks still include a browser detection function and its always good to have that information to hand for when an object check is not possible.