Professional browser support

A while ago I wrote this post about aggressive browser spitting, in which I blame ourselves for the fact that we still have to support ancient browsers. In that post I propose an aggressive approach to browser support: if your browser doesn’t understand the current web standards it’s the browser’s fault, not mine. The browser vendor should fix it, not me. This, of course, is very hard to sell to clients. But you can definitely use it in your personal projects.

Some discussions with Albert de Klein, Robert Jan Verkade and Wilfred Nas (among others) kept me thinking about this issue.

For client work a different approach is needed. Not the classic approach based on amount of users, I think we can still take a certain level of standards support as a baseline. I like the way how The Guardian and the BBC do it. A lot. If your browser doesn’t support at least localStorage (needed for performance), querySelector and addEventListener (both needed for sensible JavaScript) it will get an experience without JavaScript. Mind you, this does not mean that these people will get an ugly, unusable site. This means they get a well designed site without any enhancements.

But how?

Certain components will need several designs. We are getting used to this idea when we talk about multiple layouts for responsive design, but we’re not yet used to designing these different experiences. In his new book — which you should all buy now and read — Stephen Hay explains the idea of the breakpoint graph, a way to document the different appearances of components. Incorporating these breakpoint graphs into your workflow might help yourself in designing for these older browsers. These graphs will also help you in convincing the client that an experience without JavaScript is actually pretty good.

And if that doesn’t convince them, just tell them it will cost them money if they want more support. Lots.