Three Takes on Browser Compatibility

Updated: November 4, 2010

Cross-browser web development is hard; don’t let people tell you otherwise. Look, as the Web moves forward browsers that used to be great suddenly become <euphemism>not good enough</euphemism>. We want to use the newest features and standards, say the File API and WAI-ARIA, and we don’t want to wait. But what if it doesn’t run in Browser X? What if the KillerShark screen reader doesn’t pick it up? What do we do?

The answer is: it depends. But you know that trick already, so let’s cut to the chase: okay, there is no one-size-fits-all answer, but there are different strategies that we can describe with their pros and cons. I’m going to flesh out three wholly different strategies, three extremes that you may want to try to balance while keeping in mind your site’s goals.

Three Extremes

  1. Do it all.
    Just make it work, OK? Take all the time you need. Mix progressive enhancement and graceful degradation and fallbacks and alternative versions and User Agent detection and whatnot. Every single trick in the book. Yes, we will support Old Browser version 4, and disabled users. Heck, we’ll even support disabled users stuck with Old Browser 4 (a deadly combo), while showing magical ponies to the browsers that support CSS Pony module. This will take forever and will cost an arm, but it will run everywhere and we’ll reap maximum benefits.

  2. Aim for the top.
    Stop caring so much for old User Agents1, and focus on the newest standards and features instead. The new things you can do will blow your mind, and the old stuff will be much easier to do, too. Of course some users, and sometimes a lot of them, will not be able to use your site or this awesome feature, so you’re narrowing your audience… but with that audience, you get a competitive edge. It’s okay to differentiate and do a niche product—you know, the profitable kind.

  3. Keep it low.
    Why lose those users on old software, minority web phones and stuff? It’s better to stick to the baseline, you know, the standards that are implemented already and consistently. Development will be easier. Debugging is easy, as we’re experts, we know what works everywhere and what doesn’t, we can avoid the traps. Accessibility? We’re doing it from the start, it’s part of the process and barely raises the costs, if at all. We won’t have bells and whistles all over the place but what matters most is to get the basics right—that’s where the real money is.

Which One Should I Do?

Beats me.

Okay, you probably don’t want to go full steam ahead with one of those strategies. It’s better to mix and match. For each project, you will pick a development philosophy and refine it. But how?

There are lot of factors computing in. Vision is one. Like when you know or feel that you can make something special by aiming for the top. Maybe you or your client favors the quality of the experience rather than the quantity of supported user configurations. Make sure that approach will fit your current brand or the brand you’re trying to establish.

Keep your goals in mind. If you’re a public institution or administration, people will expect you to provide support for everybody. This is probably highlighted in your mission statement. So you will want to keep it low and focus on service and usability rather than bleeding-edge technology.

Scale is critical. The intended scale of the project should determine what resources you use, and it will influence your goals too. If you’re one of the very big guys, you may want to do it all and support as many potential users as possible. Or you may want drop support for old browsers in order to push new technologies, because it fits your brand and your long-term strategy.

My Boss/Client Wants It All But Has No Money

You have to say the N-word: No. Also, it might help to talk to your boss/client and try to explain. Feel free to be specific and point the cost of this or that if you want to. But if you want to be less specific and more schematic… meet the browser support triangle:

Cheap — Compatible — Innovative.

Cheap, compatible, innovative. Pick two.

Perfect compatibility and innovative features? It won’t be cheap.
Great compatibility in a cheap project? Stick to simple features.
Want to be innovative2 on the cheap? Don’t support older browsers.

If it sounds familiar, that’s because I’m just rehashing the same “three strategies” idea. But repetition is good, and we got ourselves a variation on the project triangle in the process. Score.

Finally, remember that this is the schematic view, and in your projects you will have to mix and match, just like we said earlier.

  1. To keep it simple, User Agents, in W3C lingo, are tools that interpret your code and show the result to a user. Like a web browser, or a screen reader.
  2. I’m using “innovative” a bit frivolously. I don’t mean stuff that nobody has done before, it’s more like features of browsers that your competitors are too afraid to use because not every browser supports them.

Comments