Dealing with older browsers

After working in the web development industry for the last 6 years or so, dealing with older browsers that lack decent support for CSS and Javascript is something I face and deal with on a near-daily basis. Why near-daily? Well, I do a lot of Server side development which tends to be browser agnostic.

Dealing with older browsers is a problem that MUST be solved, or handled, one way or the other. Some solutions are more involved than others and some solutions will not be accessible under certain situations. One option that I think gets ignored all too often, is the possibility that older browsers simply get a different experience, visually and behaviorally.

Why does this option get ignored? Well, in my opinion, its usually the arrogance and/or ignorance of designers. I’ve dealt with a reasonable number of designers so far in my career and almost without exception, designers insist on having the UI look, feel and behave exactly the same on “all” browsers. For the most part, what this really means is make it work perfectly on IE6. Most people have completely ignored all versions of IE below IE6, and other browsers that are more than say, 10 years old.

IE6 has been in the market for about 8 years now I believe, but somehow it still manages to hold a good proportion of the browser market share, even though IE8 has just hit the market within the last 6 months or so. IE6 has a multitude of CSS rendering bugs (3 pixel jog, double margin, peek-a-boo to name just a few) as well as a number of Javascript quirks that make life less than simple when it comes time to develop a frontend for it.

Most frontend developers will create their first “draft” of the site on Firefox, simply because the advent of the Firebug plugin, it has the best tools to help debug any Javascript and CSS issues that might arises, not to mention its DOM viewer shows you the DOM after any Javascript modifications have taken place. A handy tool indeed if you’re playing around with Ajax. Once the site looks and behaves the way it should on Firefox, it’s a relatively trivial job to fix any bugs that might arise on Safari, Opera and Chrome (which uses the Safari rendering engine). Handling IE8 and IE7 is reasonably simple as well because the IE Development Team have made huge leaps in correcting the problems that plagued IE6.

Unfortunately, handling IE6 is far from simple. It often requires a whole new stylesheet with dozens of modified rules to handle each all the little quirks that are exposed by the IE6 rendering engine. In my experience, if you make heavy use of positioned or floated elements in your layout, which is pretty much a given these days, you’re going to have problems with IE6.

Now, if you have to make the layout and behavior match exactly the same in IE6 as Firefox3, this can often lead to many, many extra hours of CSS debugging and Javascript tweaking to have an experience that even closely resembles what the designer intended. The advent of Javascript Frameworks like jQuery and MooTools greatly simplify the Javascript burden, but CSS is not quite a lucky. CSS Frameworks exists (think 960.gs or Blueprint) but I doubt they manage cross browser issues as well as Javascript Frameworks do.

So where do you draw the line? As far as behavior goes, most developers strive to make the entire site without Javascript first (or at least they should), then add the Javascript required to make the experience simpler or nicer. This is known as progressive enhancement. By taking this approach, you guarantee that the site is usable, one way or another. Progressive enhancement also applies to CSS, but very few developers make use of it for the simple fact that feature detection is not as simple in CSS as it is in Javascript. With the pending arrival of CSS3, which comes with a large number of improvements, such as rounded corners, drop shadows and a slew of new selectors, which go a long way in solving a number of common layout problems. Being almost 10 years old, IE6 cannot make use of these new CSS developments.

I’m a huge advocate of leaving IE6 to its own devices, simply because IE7 has been on the market for about 2 years now and IE8 has been out since the beginning of 2009. There is no need to continue to offer support what has long been considered a thorn in the side of the web developer’s, and web designer’s side. But that decision is ultimately up to the client, which in my case is often a designer.

If I knew it was okay for me to give IE6 users a slightly different experience, be it just layout or both layout and behavior, the time I would have to spend correcting any issues in IE6 would be greatly decreased. Less time spent flogging a dead horse, means faster project turnovers, which ultimately means more profits in the long run. As with most “diseases”, prevention is better than cure, so if designers and/or clients were more willing to flex a little, they would realise that allowing a dying, diseased beast to dine with the healthy often means the healthy suffer in the long run. Hopefully, that day is just around the corner. Until then, I guess I’ll have to keep plugging away on the shit bucket that is IE6.