Best practices for cross-browser development

My last big project was the development of a public-facing web site. One of the issues that such web sites face that isn’t a problem for internally-deployed apps is browser compatibility. While an in-house app theoretically only has to support one flavour of browser (whatever the CEO uses, of course), a public facing app should support a range of browsers.

It was brought to my attention today that I’ve never outlined the processes we used to minimize cross-browser incompatibilities. This won’t be an exhaustive list, but will hopefully hit the high points.

Use a framework that minimizes cross-browser issues

There are quite a few choices here. jQuery is probably the standard go-to library for this sort of thing in the JavaScript/DOM/AJAX space. We used GWT, which allowed us to focus on the functionality of the site without worrying overmuch about browser behavior. GWT, in a nutshell, turns Java classes into JavaScript that is interpreted correctly by a wide range of browsers.

Either ignore IE6, or be prepared to spend a lot of time on it

IE6 is still a thorn in the side of web developers everywhere. There are a lot of issues with the browser: it was released nearly a decade ago, it has had multiple security issues identified, it has been replaced by three newer versions and it is no longer fully supported by Microsoft. It still reports a 10% market share – either a lot of people are running an outdated, insecure browser, or there are a lot of devices and other apps that are self-reporting as IE6.

The problem with IE6 is that is behaves differently than any modern browser, but it was far ahead of its contemporaries in its heyday. At the time, a lot of web apps were build specifically for IE6, making full use of its advanced functionality. Those same webapps will now run on nothing but IE6, locking in a portion of the corporate base to this outdated browser. Modern webapps generally don’t run well on IE6 unless a lot of time is spent supporting it.

Realistically, you have to determine if IE6 support is worth it. I’d estimate that half of time we spent on cross-browser issues was spent specifically on IE6. Depending on the demographics of your audience, this may or may not be acceptable.

Build browser testing into your process

The most important element that we added to our process was to constantly test the site throughout development using a wide range of browsers. We did this by assigning each developer and QA person a preferred browser and version. Given their own choice, developers are always going to choose the latest version of Firefox or Chrome. Taking this choice away ensures that someone views the site using less-than-current browsers every day, and the payoff is that you won’t be surprised when your site goes live.

It's only fair to share...
Share on FacebookGoogle+Tweet about this on TwitterShare on LinkedIn

Leave a Reply