
Cross browser testing can be difficult. Many of you lived and worked through the first browser war of the mid nineties (henceforth referred to as BW I). Things settled down for a few years while we waited patiently for Firefox to rise from the ashes of Netscape and challenge Internet Explorer’s dominance. Those years are past and the second browser war has begun (BW II). Counting the just released beta of Internet Explorer 9, we have had three new versions of IE in 4 years. Compare that to the previous 5 years which saw no major versions released. Google’s browser Chrome was first released in 2008 and is already on version 6. They recently announced a plan to have a new stable release out every 6 weeks. That is over 8 releases a year. Considering only those two, we have a lot to test against. Yet to get the full picture you’ll need to add in Safari, with roughly one major version release each year, and Firefox which is currently beta testing version 4 of their browser. Oh … and who could forget Opera.
Adding mobile just complicates things more. We now have 4 generations of iPhones, 1 generation of iPads, and countless Android, Blackberry and Windows Phones on the market.
Don’t get me wrong, I’m glad for BW II. Things have gotten really exciting in web design and development in last few years. We’re starting to see huge advancements in CSS support including things like drop shadows, multiple background images, rounded corners, gradients, and more. With HTML 5 we have native video and audio support, built in form validation, local storage and tons of other long over-due features. It is a great time to be a web designer.
So with all of this change, how do we possibly ensure that our websites work where they need to? How do we test for all of these browsers?
Graded Browser Support
In the years of the BW I, browser support was often all or nothing. I’m sure you remember encountering sites that behaved like a cool kids club and blocked your access if you were using the wrong browser, “yo this site was designed for Netscape 4”. We’re past that. A better approach is to provide graded browser support built on the principle of gracefully dropping features for less capable browsers. By intelligently defining a few levels of support you can take control of what is supported and what is not. It will help you set priorities on testing and give some freedom to play with new features without having to make sure they work in Internet Explorer 6.
So let me outline an example of graded support using 4 levels. I’d recommend 3 or 4, any more than that and it’ll get way too complicated. We’ll use letters of the alphabet to identify each level (we work at schools, this should make sense to us):
A – All features work and the design is how we intended it to look. All sites are tested in these browsers and display and functionality problems are addressed with the highest priority.
B – Some advanced features of the design may not work exactly how we intended, but all sites are 100% functional in these browsers. All sites are tested in these browsers and display and functionality problems are addressed with secondary level of priority.
C – Sites will likely not have all of the features and the design may not look as nice, but the sites will be mostly functional in these browsers. These browsers are in a secondary test suite and only major pages and templates will be tested. Display or functionality problems will be addressed with the lowest level of priority.
D – Sites are not tested in these browsers. This does not mean they will not work, but we don’t actively test or develop to these browsers and as a result our sites may not function. Display and functionality problems will not be addressed.
Based on these levels and the current browser market this might lead to a chart formatted something like this:
|
Windows |
Mac OS |
Linux |
Mobile |
| IE 9 |
a
|
|
|
|
| IE 8 |
b
|
|
|
|
| IE 7 |
b
|
|
|
|
| IE 6 |
c
|
|
|
|
| IE 5 or less |
d
|
d
|
|
|
| Firefox 4 |
b
|
b
|
d
|
|
| Firefox 3 |
a
|
a
|
d
|
|
| Firefox 2 or less |
d
|
d
|
d
|
|
| Safari 5 |
b
|
b
|
|
b
|
| Safari 4 or less |
d
|
d
|
|
d
|
| Chrome 6 |
b
|
b
|
d
|
b
|
| Chrome 5 or less |
d
|
d
|
d
|
d
|
| Opera 10 |
d
|
d
|
|
d
|
Which browsers to support
How do you decide where to place each browser in the chart? Check your stats. What are your users browsing your site on? If I look at my school the answers is:
- Internet Explorer on Windows – 55%
- Firefox on Windows – 18%
- Safari on Macintosh – 12%
- Chrome on Windows – 7%
- Firefox on Macintosh – 3%
- Safari on iPhone – 0.7%
- Safari on iPad – 0.3%
So based solely on those stats most of my effort should be focused on Windows browsers (80% of users), followed by Mac OS (12%) with minimal support for mobile and Linux. But I wouldn’t recommend making all the decisions based on current numbers alone. When it comes to emerging platforms (specifically mobile) your support for the platform may have an impact on its growth. At our school, which has essentially no mobile support, there was 150% increase in the number of visitors using mobile devices semester-to-semester. WVU, which has a healthy mobile presence, saw 200% increase semester-to-semester. This may only be a small difference and may only be anecdotal, but it is worth considering that mobile growth on your campus may be slowed by your lack of attention to it. So while logic based on the numbers might land mobile browser in the “d” support level, growth and desire for continued growth might make you want to bump it up to “c”, “b” or even “a” level support.
Now as we have established, things are moving fast so you’ll need to check in on this on a regular basis. Perhaps you could plan to update it monthly when you are checking your stats to send it the Higher Ed Analytics Benchmarking Survey. Just take a second, look at the browser stats and see if you need to make adjustments. And hopefully soon you’ll be dropping IE 6 to “d” level to make room for best, faster, safer and funner browsers (one of those may not actually be a word, but as I’m sure you have noticed I self edit).
The point is:
Don’t worry about pixel perfection in old browsers when you could be living in tomorrowland* today.
*Tomorrow land is prettier and more usable.
and use graded browser support to help move forward and gradually migrate old browsers out of your testing suite.
Tomorrowland things you can start using today
CSS 3 supports rounded corners, but some browsers have not picked it up yet. You could just wait to use them until all of the major players jump on board, but why? Rounded corners degrade beautifully. Browsers that don’t support them simply fall back to sharp corners, and sharp corners on the web are pretty harmless. So depending on the browser you are using to view this page the chart above will look like either the left or right example below. So you decide? Is there any harm in using them now? (go play)

A second example is transparent PNGs. All current major browsers support beautiful alpha transparencies in PNG files. Internet Explorer 6 does not support them out of the box. You may have noticed in my chart above I placed IE 6 at level “c”. This basically means that our sites might not be pretty in it, but they’ll work most of the time. Below is an example from USC (thanks Tim). You’ll notice that the IE 6 example doesn’t look as nice as the IE 8 version (ugly gray backgrounds), but it is 100% functional so it is acceptable in our graded browser support. The beauty of using a transparent PNG here is that if somewhere along the line USC decided to change the background colour behind those images they could make a quick CSS change without having to go back and re-export the icons (because it is REAL alpha transparency).

There are countless other example I could pull out, but instead I’ll just give you a few links:
Are you living in tomorrowland?
So have you embraced some forward thinking approaches? Do your web designer know what browsers you support? Does your website have a pretty table with CSS rounded corners? Let me know in the comments. I’ll see you all in tomorrowland.