One of the realities of modern web development is that you’ll often have code which behaves differently depending on the web browser you’re using. In the past, this conditional code was usually intended to work around incompatibilities in the CSS standards support for the various browsers, but this may become less of a driver as compatibility improves across the board. Ironically, the renewed focus on AJAX applications means that browser detection will now become more important for detecting non-standardized capabilities of a browser in order to leverage them in an application.
As an example of this, consider how DasBlog enables rich HTML edit. DasBlog uses a freeware component called FreeTextBox, which enables rich HTML edit on both IE and Firefox. The problem is, FreeTextBox thinks that IE7 is Firefox. That’s because FTB uses an algorithm like:
Note the problem here — all of the IE versions are very precisely defined, and Netscape is defined to be everything else. This is a very common pattern in browser detection, which can lead to buggy behavior. There are a number of reasons I can imagine that people would use a browser-detection pattern like this:
- They are developing on IE primarily, and consider all other browsers to be lower priority in testing. Google hits for “Works best in Internet Explorer” often fall in this category.
- They are developing to standards first, probably using Opera, Netscape, or Firefox as the litmus test. They find that code which works in their primary development browser needs to be hacked to work in IE. Note that the standards-first approach is what I prefer and recommend; however it is probably not the most common approach.
- They want to take advantage of specific built-in proprietary functionality (such as rich edit or XmlHttpRequest) of IE to provide an “uplevel” experience. That’s clearly the case in this specific example. Firefox has been matching some of these libraries which have been in IE for several years, so the situation here will change.
Now, regardless of the reason that the above browser detect code is used, it’s probably not the right thing to do. In this case, the detection code is going to decide that IE7 is “anything other than IE”
So you have to consider what happens if your site mistakenly thinks that IE7 is “non-IE” and starts feeding it the non-IE code. If the “non-IE” setting was intended to mean “more standard CSS” (as it often is), then you might not even notice, since IE7 is a bit better with CSS. But if your app is using any hot “new” AJAX stuff, and the “non-IE” setting really means “downlevel experience” (as it also does sometimes) you really want your app to know that IE7 is a version of IE.
Of course, the best thing will be to test your site in IE7 as soon as it becomes available. But in the meantime, you could check your browser detect code and contact any component vendors used by your site to make sure they are thinking about this. See IE Blog and Dave Massy’s blog for some tips on browser detection. Both the user agent string and the navigator.appVersion (two different strings) are potential sources of trouble. If using the user agent string with tools that use browscap.ini (such as some PHP and IIS apps), you can just update the file.