Variety may be the spice of life, but Web development is 'muy picante' at times.

By KENT SHARKEY 12/13/2011 09:24:30 AM

Desktop developers have it so easy. All[1] you have to do is pick your development platform, and everything else flows from there: you know what you'll have to use for your screens, you have a pretty good idea about screen resolution, and what operating system your program will land on. Not so with Web development. Even after picking a development platform, you still have to deal with multiple languages, standards, and the whims of the client browser. Not to mention that users may disable certain features, or they may have installed some other plug-in that might interfere with your precious code. Bah.

Based on the most recent StatCounter results (Nov 2011), there are well over a dozen different browsers (including versions) out in the wild. Many of these treat innocent HTML completely different than the others.

Browser Versions, Nov 2010-Nov 2011

So, what's a developer to do? Well, you could just use 'tried and true' methods of HTML3.2/XHTML (transitional) and have really ugly pages that look like they're from the last century. Or, you could do what many desktop developers do and say, "To use my application, you must use this browser at this resolution." It might work internally [2], but it certainly wouldn't work on the Internet [3]. No, I think it's time to think more here.

First things first

Before I jump into the big tools sales pitch, it's probably worth figuring out if you really need to worry. If you are working on an internal application, and the corporate standard is "IE 6 is installed on all desktops, running XP at 800x600", then that's what you need to work with [4]. However, even with internal applications, there can be some variety in versions—or possibly even browsers—that you will need to deak with. IT may say everyone is running IE9, but accouting may still be on IE8 ("It's the only version compatible with the app the last Web developer left us with"), or there may be a few clients who want to use their new tablet to show off to a customer. So, while internal apps reduce the need for dealing with variety, they're not the final solution.


A few years back, there was a lovely component called BrowserAgent[5]. It read the headers that your browser sends with every request, and translated that into a collection of properties you could use on the server to determine what Web features the client supported, the resolution, etc. The problem was though, that the client could lie to you. Just about every browser had a feature or plug-in that enabled them to change the user agent header (the main source of this information), meaning that "IE version 15" browser your site detects not really be right. In addition, as most of the data was based on parsing the header [6], and looking up feature support based on the interpretation. Shorter version: I don't think it's that useful anymore.

Instead of trying to make educated guesses about features, why not get the browser to check itself? Web developers have been doing this for years when they wrap JavaScript in comments to prevent the code being displayed in some browsers. In addition, some features are designed to allow for relatively graceful flow of support. For example, if you want to show a video on a Web page, you could write something like the following.

<object style="height: 390px; width: 640px">
  <param name="movie" 
player_profilepage"> <param name="allowFullScreen" value="true"> <param name="allowScriptAccess" value="always"> <embed src="" type="application/x-shockwave-flash" allowfullscreen="true" allowScriptAccess="always" width="640" height="360"> </object>

Notice that the embed tag is included within the object tag. This means that the browser will first try to instantiate the object, then the embed. YouTube could also have included something for those who don't have any way of supporting video playback, but I guess they figured that wasn't likely. Many of the more highly variable new features in HTML—like the object tag—have support for this fallback support. However, features like the new HTML5 elements or new CSS3 attributes do not.

You could look at your Web server logs and figure out what features are possible for the majority of your users. The site Can I use? can be quite handy here as it shows the support for various HTML and CSS standards.

Can I Use: rounded corners

Alternately, you can try to instantiate features, to see what's possible. This has the advantage that as it's working within the client browser, it will work properly, even if other code interferes with your detection. Also, it helps future-proof your application as feature support improves. This could be quite labour-intensive though: who wants to write (and debug) all the code needed to track all these features?

You knew where this was going, didn't you? Modernizr is a JavaScript library that has done all the hard work for you. Want those "OhSoSexy" new HTML5 date input field? Do a quick check first:

  test: Modernizr.inputtypes &&,
  yep : /*nothing needed, it's supported*/,
  nope: /*load jQuery UI scripts and CSS*/
  both: /*We always want jQuery, don't we? Oh, yes we do*/

Or even just on the fly:

if ( ) {
  /*add other input here*/

While it doesn't fix the problems caused by all those browsers, it certainly helps avoid their side effects. It even gives you hooks to load in alternate solutions (like jQuery UI, CSS Pie or other libraries) so that your features work mostly the same in all browsers. And I guess that's as close as it will get. At least until all the browsers in use support all of the HTML5 and CSS3 specifications.

Of course then we'll be wanting those great items from HTML6…

  1. Yes, my tongue is firmly planted in my cheek.
  2. And may the Flying Spaghetti Monster save you when a VP asks to be able to use it on their new iPhone.
  3. Fortunately, the days of "This site works best on …" notices have gone the way of blink tags. I hope.
  4. At least until you can find a better client.
  5. It may still be around, and apologies to the makers if it is, I just think it's irrelevant now.
  6. Really, you want to write the RegEx for parsing something like: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; GTB6; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; OfficeLiveConnector.1.4; OfficeLivePatch.1.3)?
  7. On an only vaguely related point, there is definitely a lesson here for the benefit of automatically upgrading applications. Google Chrome does this, either on startup, or it will warn you if you haven't restarted in a while. The end result is that you get waves of browser versions, with the most recent at any given time being in the majority (it's a little muddier, as people can be using a future version of the browser). So, if you haven't investigated some sort of auto-upgrade mechanism (for example: ClickOnce on .NET, Web Start on Java, or your own custom implementation), you should. It might just save you some support time in the future.
    Google Chrome versions, Nov 2010-Nov 2011
    Compare this to a more traditionally installed program, say IE. Notice that older versions diminish, but never go away.
    Internet Explorer versions, Nov 2010-Nov 2011
Application Development
Let Apptius save you time and money by adding functionality to your existing programs.
Microsoft Outlook
Apptius offers professional development services for custom Microsoft Outlook solutions
Microsoft Outlook Logo