I am well and truly on my way to grumpy old man status - at least in the web
development world. I started my web development career when Mosaic was new, and
I knew all the tricks to getting Netscape to behave. I was even excited when IE4
came out and predicted, widely and vociferously, that a new age of a simpler,
more sensible HTML and CSS cross browser standards had arrived. An Age of
Aquarius with developer and browser living in harmony, dancing in the meadows
and tripping on .htc files.
As I look at the dark storm clouds outside, the rain sheeting down my
Windows and the lightning flickering in the distance you'll forgive a snort of
Developing webpages today means you need to test against dozens upon dozens
of browsers, devices and configurations - and that's not even including testing
tablet, mobile, IE6+, Firefox 23 and Chrome Eleventy-oneth (or whatever it's up to this week)
are all popular. At least WAP had the good sense to crawl behind the shed and
leave this mortal coil.
Testing your HTML and CSS
So what do you do with all this choice? A few options:
- Get someone else to test for you. Let me know how that goes for you.
- Don't test at all. Again, let me know how that goes.
- Declare with the certainty of a zealot that any browser that doesn't
render your site correctly is an aberration to be shunned and would never,
ever be used by your discerning readers. Remember that the first step in solving a problem is admitting you have one in the first place.
- Code your HTML using the most basic, most foolproof tags and layout that
is guaranteed to work on all browsers. This is actually a bit of a catch-22
because in order to avoid testing by using only tags that work perfectly on
all setups you'll need to test to ensure that they, well, work perfectly on
- Test manually against all browsers. And lead a dark, cynical life
- Test against the setups you know 98% of your users will use and ignore
the rest. If someone is going to use Lynx to view your site and then
complain the images don't render then you're not going to win. Ever.
Testing against the 98% set is my personal recommendation that carries with
it a caveat: allow your users to easily report issues with browsers you test,
and occasionally test the majority of your functionality against a browser
not in your
top 10 list. You don't have to be perfect for everyone all the time.
Just ensure you're at least functional.
CodeProject's typical browser spectrum will be IE, Chrome, Firefox, Safari
and Opera, plus their mobile equivalents. Plus their various versions. IE usage
for us is less than 1% for IE7 and below, but that still leaves IE8, 9 and 10.
Firefox sees versions from 5 to 23, and Chrome is out of control: Just the top
10 versions of chrome show 5 minor versions of version 26. That's a lot of
variation but thankfully browsers are actually settling down (though
occasionally, such as Firefox 17, rendering issues do pop up).
From this our (simplified) testing regime looks like
||Windows and Mac
||Windows, Mac and Android
||Windows, Mac and iOS
And a secondary set of tests against earlier versions of the non IE browsers
Note the big problem here: We're testing only against the latest versions of
the most popular browsers because they all (sensibly) aggressively update
themselves. IE has finally started doing this and also provides (via F12 Developer
Tools) excellent support for testing against older versions. For the other
browsers you either need to install multiple versions or use a VM. And for
testing on different Operating Systems you need a second computer or devices or
VMs or emulators.
An important note is that while Chrome and Safari were using the same WebKit
Google announced they will be forking WebKit to create Blink. Whereas
testing against either Safari or Chrome was usually a good enough test against
both, this will no longer be as solid a proposition in the future.
Multi-browser testing options
Over the years I've used 4 solutions for testing multiple browsers (above and
beyond simply installing all browsers
- Spoon.net. This works as a browser
plugin that provides access to tons of different browsers and apps that run
on-demand inside a sandbox. Support for IE was discontinued for some time so
I switched to...
IETester. This single install allows you to run all versions of IE from
5.5 to 10 within a tabbed environment. A little hit and miss and debugging
your script and HTML was not always successful, but at least you could test
- Device specific emulators or tools such as Safari's Web Inspector on
- Modern.IE. This is my new best
Getting multi-browser HTML testing right
Ignoring my opening paragraph about the dark days we live in, browser testing
is actually a lot easier now than previously because browsers are all working
towards HTML5 compatibility, and with modern browsers all auto-updating we're
less and less likely to have stragglers hanging on to old, outdated, poorly
rendering and insecure browsers. My advice for those writing HTML is to target
HTML5 from the start and to use CSS3 (and maybe
for the fancy stuff. Keep your HTML clean and avoid hacks. I will ignore
subject that does bad things to my blood pressure. Just use jQuery and pray.
Targeting HTML5 will future proof your mark up far better than doing things
like using IE conditionals. The developer community is aggressively pushing
developers and by extension, users to stick to modern browsers and so HTML5
will, very quickly, be your 95-98% water mark. If you truly need to hack
to fix an issue then use
responsibly. Work out whether the issue is simply bad CSS, try to find a
non-hack workaround, but if you end up with a client who uses IE4 and there's no
way to back out then a well marked, well documented, centralised CSS hack can
save you doing something dangerous with your HTML.
So this means we're down to testing, as our main targets:
||Windows and Mac
||Windows, Mac and Android
||Windows, Mac and iOS
And a secondary set of tests against IE 8/9 and earlier versions of the other
browsers. Much simpler. Except for the operating system and platform bit.
Checking before Testing
Before you test your page you need to check your page. There's no
point in iteratively fixing your HTML across multiple tests on multiple browsers
if you're starting with suspect HTML to begin with. Enter Modern.IE.
On Modern.IE you just enter the URL of the site you wish to check and it runs
a bunch of checks to ensure you are targeting standards and checks common
compatibility problems. Its goal is to "suggest a fix or enhancement with web
standards like HTML5 & CSS3 (or a graceful fallback)".
So let's try a website such as, say, Microsoft.com. Enter the URL, hit scan
and you quickly get a neat summary and suggestions for issues. Right off the bat
it's suggested a way to increase site rendering performance by 30% on newer
browsers and provides a link to walk you through exactly how to achieve this.
All good so far. We've scanned our pages, implemented or, as the case may be,
completely ignored the suggestions, and have our site. To testing!
Testing Multiple browsers on Multiple Platforms on Multiple Devices. In the
I really need the
Shamwow guy for this. It's really that good.
On the Modern.IE homepage you'll see under the tastefully Orange section a
blue "Try BrowserStack"
link. Try it. Live it. Love it. (You will need Flash, though).
Choose your platform, your OS and even the device and then enter the URL and
But wait! There's more!
Obviously testing against production is painful in that your cycle will
involve deploying between each update. That can hurt. To solve this BrowserStack
connects to your local server for full local testing. Test against live on one
device, test against local on another:
Some final words
Two things I should point out
- Modern.IE's scanner can be
and run locally.
- BrowserStack isn't free. You get a 3 month free trial after which it's
$19 a month for a single developer license. Spoon.net, in comparison, is
free for basic apps and $12 a month for all apps. However, spoon.net does
not include support for testing on specific Operating Systems or devices.
Browser testing really depends on the specifics of your application and
audience. If you absolutely, positively require that your app only runs on IE6
because your company has stuck to XP and will not, ever, in a million years,
upgrade, then multi-browser testing your internal intranet app may not be a
productive use of your time. Another consideration is that my 98% rule of thumb
may be completely inappropriate for you. 99.9% of your users may be perfect net
citizens and use the latest version of IE10 or FireFox and everything's great,
but your CEO is blind and uses a screen reader. You really need to test against
Further, browser testing is no substitute for user testing, security testing,
accessibility testing or any of the other things you need to test. It's part of
a balanced testing regime.
Be pragmatic, code against the standards, avoid the hacks and aim to have
something wonderful for almost everyone, and tolerable for the recalcitrant or