A Low-Tech 80/20 Approach to Cross-Browser Development

December 16th, 2011 Permalink

Supporting the full range of popular browsers for a standard-issue website has rarely been as easy as it is now, at the end of 2011. "Easy" is a comparative term of course, but these are far better days than, say, the Netscape 4.* or IE5.* eras. It is presently reasonable to expect to be able to straightforwardly write a HTML/CSS/Javascript codebase that produces the same pixel-perfect web pages for all of the (non-mobile) browser versions that matter.

(If you're a mobile web developer, you're still buried somewhere in the fifth circle of Hell whilst contemplating the seventh, of course - but I'm wisely choosing to exclude all of that from the bounds of this post. It has been observed that mobile development is going through the process of recapitulating the last fifteen years of non-mobile development, and it seems that a horrific and fractured web development environment is a necessary part of that show for now).

In any case, here I'm going to outline a few important highlights of my methodology for working on the look and feel side of a non-mobile website: taking a design, turning it into HTML, CSS, and Javascript, and having that end result produce the same output in variety of browsers with as little pain, rework, and exploration of web page rendering oddities as possible.

Use the HTML5 Doctype

Even if you ignore everything else about HTML5 (and I think that there are reasonable arguments for doing just that), you should be using the doctype. All your pages should open with:

<!doctype html>

This will make your life easier. My anecdotal experience has been that the present mainstream browsers are closer to one another on the finer points of rendering HTML5 than for other forms of HTML. Enough time has passed for fragmentation to begin, but apparently there has been little incentive for that fragmentation amongst the major players in desktop browser development in recent years - for which we can all be thankful.

Use the HTML5 Boilerplate Project

The HTML5 Boilerplate project will save you a great deal of time and effort, as it is essentially a gathering of best practices, quirk resolutions, and small solutions for HTML5. I find that the greatest benefits come from (a) including the boilerplate CSS into my projects, and (b) the project's approach to arranging CSS styles for old browser versions. This second item employs conditionals in the header:

<!doctype html>
<!--[if lt IE 7]> <html class="no-js ie6 oldie" lang="en"> <![endif]-->
<!--[if IE 7]> <html class="no-js ie7 oldie" lang="en"> <![endif]-->
<!--[if IE 8]> <html class="no-js ie8 oldie" lang="en"> <![endif]-->
<!--[if gt IE 8]><!--> <html class="no-js" lang="en"> <!--<![endif]-->

Thus you can write CSS declarations needed to compensate for older IE versions as follows:

.ie6 my-floats {
  display: inline;
}

And so forth. This might not seem like much when given as an example like that, but it makes a big difference in practice when it comes to organizing, reviewing, and patching up CSS.

Develop in Chromium, Review in Firefox With Firebug

When actively engaged in developing a website, I keep both Iron (a Chromium fork) and Firefox up and running. I use Iron to eyeball web pages as I build them, and then Firefox and Firebug for the more exploratory changes, tests, and experiments. I find that Firebug remains a better browser interface for making changes to HTML and CSS on the fly, meaning that - for me at least - it is faster to use and more intuitive. Unfortunately, I can't just run all my development in Firefox, as when I build a site using Firefox to eyeball the pages along the way and then later review in a WebKit based browser like Chromium, I usually find more cross-browser issues. A page built to look great in Firefox will generally have more minor issues in a WebKit browser like Iron than a page built to look great in Iron is going to have when viewed in Firefox. This is the case for me, anyway.

So given this experience, I have adopted the mixed mode of development in two open browsers described above. For me, it ensures that I see as few WebKit-versus-Mozilla quirks as possible at the end of the day. It also means that when I later review the results in Safari, another WebKit browser, I rarely find any problems. (Mobile Safari is a whole other story, but as I pointed out above, I'm conveniently not talking about mobile development today).

Patch Up the CSS For Internet Explorer at the End

Once you have things finished up and looking good in Mozilla and your WebKit browser of choice, then move on to patch up the CSS to cover the oddities of IE6 through IE9. For me this is a two-step approach: firstly, use a tool that will walk through your CSS and churn out an additional set of targeted rules to deal with the known issues with older browsers. I've used ie6fixer in the past with no complaints, for example, and it's easy to take the output and prepend each rule with ".ie6" to go along with the conditional header from HTML5 Boilerplate. There are many good tools out there. The second step is a review of the site in a tool like IETester that allows you to launch multiple IE browsers of different versions. Walk through the site in the various version of IE, find the remaining problems, and fix them by hand.

And Then the Hard Stuff

By this point anything left should be either (a) a legitimate case of needing to polyfill a missing feature in an older browser that is required by the site design, or, if you're unlucky, (b) a novel and ornery way in which requirements and an otherwise trivial browser difference can gang up to form a blocking can of worms. But the point of my methodology is that by developing in this orderly way, and relying on the use of good, free tools at each stage of the process, I can greatly reduce the odds of encountering that unpleasant second option.