Browser testing CSS and JavaScript

After reading Andy Clarke’s article CSS: Browser testing order I’ve been thinking a bit about my own approach to testing CSS and JavaScript during development. My testing order, why I test in the browsers I do, and why I do it in that particular order. I’ve never taken the time to document my testing process, so this was a good opportunity to get it done.

First of all, at NetRelations we rarely mention specific browsers to clients. Doing that seems like a thing of the past to me. Instead we mention the standards browsers need to understand in order to handle full functionality and design, and explain that the content will be accessible regardless of which browser the visitor uses. The only time we do mention specifics is when a client asks for a detailed list of supported browsers, and that has happend only once or twice in the last several years.

When you look back a few years browser market share was always very important in every project. To me it felt like everybody (well, mostly project managers and Microsoft-oriented developers) was looking for reasons to exclude this browser or that browser, this group of users or that group of users. Sure, there are plenty of shops that still have that mindset, but it feels really backwards.

Ok, enough of that, here is my personal browser testing order. It has turned out to work well for me, but it won’t work for you unless you’re a Mac user:

1. Firefox, Mac OS X

Firefox is not my favourite browser for “casual” browsing, but when developing a website, especially if I’m doing JavaScript work, nothing beats it.

2. Safari, Mac OS X

Safari, being my browser of choice for non-development stuff, is next. It’s always running anyway, so it only takes me a couple of seconds to check that everything is still ok, which it almost always is.

3. The rest of the good Mac browsers

Time for the big browser launch. When something major (a full page template or a particularly tricky part of a design) is done I give it a quick check in the latest version of every browser that runs natively on Mac OS X. Currently that means Camino, Flock, iCab, Netscape, OmniWeb, Opera, SeaMonkey, Shiira, WebKit Nightly, and any other newcomers. I load the page, increase/decrease text size, resize the browser window, that kind of thing.

At this stage it is very rare for any problems to occur in browsers other than iCab and Internet Explorer. iCab is usually pretty much OK, with perhaps just a couple of cosmetic glitches.

4. The bad Mac browser

Before leaving the Mac OS X environment I take a quick look in Internet Explorer, where things can be a real mess. If the layout is too broken (i.e. the site becomes hard to read or use) I spend a few minutes trying to make it behave. When those few minutes are up I have either found a reasonable fix for the problem, or will change my @import rule to use single instead of double quotes to hide the CSS from IE/Mac. Unless the client has specifically mentioned full CSS support for IE/Mac as a requirement, of course, but that has happened exactly once in the last couple of years. After all, we are talking about an unsupported browser that is no longer available for download.

5. Linux browsers

I also like to keep an eye on what things look like for people using other Operating Systems than Windows and Mac OS, so I have both Ubuntu and Kubuntu Linux installed. I check Firefox in Ubuntu and Konqueror in Kubuntu. I have only experienced problems in Konqueror, but they tend to be solvable.

6. Internet Explorer 6, Windows XP

When it’s time to take a look in this browser I always start feeling a little anxious, so I don’t like launching IE/Win half an hour before it’s time to go home or on a Friday afternoon. IE 6 is the number one nerve wrecker and ulcer inducer, and this is always where any really serious CSS problems occur. Luckily I have run into a large enough number of IE bugs to know that there is almost always some kind of workaround, and its JavaScript quirks are well known and possible to work around. But as my co-workers can tell you, IE 6 is very good at sending me into computer rage mode.

7. Internet Explorer 7, Windows XP

In most cases IE 7 cooperates fairly well compared to its older versions, but it has enough bugs, weird behaviour, and general lack of support for CSS to be a serious development speed bump.

8. Internet Explorer 5.*, Windows XP

Once IE 6 and 7 have been beaten into submission, IE 5.5 tends to be OK enough as well. IE 5.0 is usually a bit less cooperative. But this check is really just to make sure the site is accessible and usable. I do not spend time making these old and unsupported browsers display exactly the same design or provide the same functionality (again, unless specifically requested, which hasn’t happened in years) as modern browsers.

9. Opera Mobile

A sanity check in Opera Mobile or, if I don’t have a mobile phone with a usable browser handy, in the Small screen view of Opera for Desktop.

10. Lynx

Checking your work in a text-only browser that has no JavaScript support is a good way of making sure that your HTML structure is logical and that your content is semantically marked up. I usually save this for last for no particular reason. It is extremely rare to run into any issues at this point since I have already made sure that my markup works without CSS and JavaScript.

One of many correct orders

I’m sure there are many more approaches to browser testing, and one order isn’t necessarily better than any other. What’s most important is to check in the most capable browsers first, and only after that start applying fixes for Internet Explorer.

By the way. As you may have noticed, the only Windows browser I check in is Internet Explorer. I have occasionally launched Firefox and Opera on XP just to make sure everything is OK, and I have never seen any rendering differences whatsoever (apart from the difference in text rendering between XP and OS X), so I haven’t seen the need. If anyone is aware of any specific differences between platforms in those browsers, please speak up.

Now then, is your testing process different from mine, and if it is, how and why?

Posted on February 26, 2007 in CSS, Browsers