One of the worst habits of web developers and designers in the mid-90s was the "this site best viewed in..." warnings. Sometimes this message was simply the developer saying, "I haven't tested this in anything else," and sometimes it really meant, "this site will not display properly in some browsers, if it works at all." Unfortunately, this trend has returned, and in some cases, it has taken on a decidedly nasty tone. For example, some sites do not display at all in Internet Explorer, and present a lengthy explanation of why you should switch to a different browser. It is your choice, but if your website is going to support as many visitors as possible, I highly recommend that you resist any temptations to go down the route of not supporting or testing your site on a particular browser.
There are four major motivations behind this that I see on a regular basis. The first is that some people, particularly technically inclined folks, have turned browser decisions into a "my way or the highway" decision, and feel that anyone not following their preference should be pushed into it. The second reason for this is that people in the tech world choose browsers like Firefox and Chrome over Safari and Internet Explorer so often that if you are in a room full of developers, it is quite likely that none of them use Internet Explorer. As a result, a kind of mental twist of reality happens, and these developers take "everyone I work with and talk to does not use Internet Explorer" and turn it into, "no one uses Internet Explorer." Another common reasoning is that because some browsers are non-standard, or require a ton of hoops to be jumped through, that there is a justification for not bothering with those browsers. It's kind of a "they won't play ball with the other browsers, so why should I play by their rules?" Finally, some developers simply do not do thorough cross-platform testing, a kind of "works on my machine, so it must work everywhere!" response.
I can understand why developers might feel these ways. It's a royal pain in the neck to do a bunch of cross-platform testing, let alone accommodate the quirks of individual browsers. The task of figuring out what those quirks are — let alone working through them, which often requires separate but logically equivalent code paths to be written and maintained — is a chore. And multiplying your testing needs not only for each browser, but for different versions is not something to lightly consider (although if you do want to do it, check out Selenium from Sauce Labs).
At the same time, ask yourself this one simple question: What percentage of potential users am I willing to sacrifice? Because as of June 2011, the "smallest" of the Big Three browsers was Chrome, with roughly 17% of the market. Even Safari is showing at nearly 7%. Can you imagine going to your boss and saying, "I really dislike Internet Explorer, so we are just going to ignore 41% of the market?" Or perhaps it is, "gee boss, it's tough to test multiple browsers, so we're just ignoring 20% of it." That's a tough proposition. For internal usage applications, you often have the ability to require (or only test on) a certain browser because it is the corporate standard. But for public facing sites and many internal applications, the attitude of hubris or laziness regarding the user's choice of browsers is simply unacceptable. Furthermore, it's easy for developers to forget that many users are required to use a certain browser. Programmers often have administrative rights on their PCs and get a choice regardless of the company policy, but the typical employee often has no ability to pick a different browser, so trying to shove one down their throats is just pouring salt into the wound.
Instead of mandating a particular browser or ignoring some browsers, here is what you can do:
- Learn the big differences between browsers.
- Specify styling in detail to account for different default styles in browsers.
- Cross-browser testing (again, look at Selenium).
- Use flexible designs that don't shatter if the browser takes some liberties with the rendering.
Justin James is an OutSystems MVP, architect, and developer with expertise in SaaS applications and enterprise applications.