In the old days of the Web, sites could choose to support a specific version or family of web broswers. These days, we don’t have that luxury. As Web Developers, we can’t know what our users will be using, so we have to support as much as we can. Of course, there are far, far too many choices. There are well over a thousand different web browser versions and brands out there, and it’s completely unreasonable to try to test every last one of those platforms.

YAHOO! talks about Graded-Browser Support in their documentation for the YAHOO! User Interface Library (which, incidentally, has become my favorite Javascript framework). Of all the methods to determine support that I’ve seen, this seems to be the best. It gives the most freedom, while still serving as a stringent guidlines. Whitelist all the A-List browsers you want to give full support to, but acknowledge that C-List browsers still exist.

There have been times where I’ve had to use lynx “Wikipedia”) or w3m to browse the web, cell phones are becoming far more common as means to access online data (our online schedule of classes get’s an amazing amount of cell phone traffic) ), and I’m reasonably certain that web browsers designed for the blind or otherwise disabled would fall into this category. A lot of fancy web application stuff would be really hard to use for people who lack all the physical capabilities of the ‘normal’ user.

Much of this has gotten far better. The text- and mobile-based browsers have better CSS support, and are better about ignoring tags that they don’t recognize. It really isn’t necessary to do this anymore:

In my personal opinion, any browser (version) that doesn’t know how to handle or ignore script tags should be classified as X-Grade these days. Ten years ago, it made sense, but not anymore. We, as web developers, need to get over the idea of the web application being more important than the web page. We need to determine a minimal level of support, and design our applications beginning at that level.

There are, therefore, two approaches to supporting C-Grade browsers. Progressive Enhancement and Graceful Failure. Planning for Graceful Failure is a flawed methodology of design. If nothing else, reread the last sentence. Planning for Failure will always succeed, but not usually in the way you want. When planning for graceful failure, you design your system to work with all these whiz-bang features, and then try to go in and try to make things work without them. This is hard, because you almost certainly made assumptions in your initial design that simply won’t hold true for the failure case.

Meanwhile, Progressive Enhancement allows you to design the for the most limited enviroment, and then slowly add in those features. You still need to keep in mind the capabilities of the ideal environment when designing the system, but those considerations are back-end issues and almost certainly won’t be problems your users will face in the front end. You might argue that it will make your code less clean, having to squeeze those advanced features in later, but that isn’t completely true. Good design will be highly modular, and the new code can leverage the modularness of the old code in manner that shouldn’t require much refactoring.

In my opinion, we need to begin our development with no CSS or Javascript. Cookies are fine, as I can’t think of anything I’d consider a C-Grade browser that doesn’t support cookies. Also, a lot of applications depend on session states anymore, and I believe that it’s best not to put the session key in the query string. It seems that a lot of people disagree. In a recent episode of FLOSS Weekly, Avi Bryant of seaside, a Smalltalk-based web framework, pointed out one of the benefits of Seaside was how well is saved a developer from having to deal with design issues, and that the application could be made to look pretty from the get-go, I really wonder how well Seaside degrades for C-Grade browsers.

In the end, I believe it’s important to maintain that C-grade experience, and improve upon it for the A-Grade browsers (Currently IE6+, Firefox 1.5+, Opera 9+ and Safari 2+). The best way to do that is to start with the most basic functionality you can afford (or are willing to support) and expand from there. I’ve been lucky in this respect, I’ve been handed several very large systems and challenged to make them something better. Most of my work has been maintenance, yes, but the point is that the product was designed for the Web 5 years (or more!) ago. Sure, some of the refactoring necessary to take the software to the next level isn’t always completely trivial, but in the end, the user doesn’t care what the code looks like, and I know the pages will be more accessible to all my users, not just the ones using A-Class browsers.