Modern.IE and BrowserStack: The tools we should have had 10 years ago.

Introduction

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 retrospective cynicism.

Developing webpages today means you need to test against dozens upon dozens of browsers, devices and configurations - and that's not even including testing to ensure things like Ad- or Javascript-blockers don't ruin your day. Desktop, tablet, mobile, IE6+, Firefox 23 and Chrome Eleventy-one^th (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:

1. Get someone else to test for you. Let me know how that goes for you.
2. Don't test at all. Again, let me know how that goes.
3. 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.
4. 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 all setups.
5. Test manually against all browsers. And lead a dark, cynical life
6. 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.

Multiple browsers

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

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 rendering engine, 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

1. 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...
2. DebaugBar's 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 IE.
3. Device specific emulators or tools such as Safari's Web Inspector on MacOS.
4. Modern.IE. This is my new best friend.

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 polyfills) for the fancy stuff. Keep your HTML clean and avoid hacks. I will ignore JavaScript in this discussion because that's a whole other teeth-grinding 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 CSS hacks 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:

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 same Window.

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 you're off.

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

1. Modern.IE's scanner can be downloaded and run locally.
2. 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 that.

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 oppressed minority.

Good luck.