Progressive Enhancement
Walter Davis
30 Dec, 2009
The idea of a Web page appearing differently depending on the browser is as old as the Web itself. Yet we spend a lot of time and effort trying to level the playing field so everyone sees the same thing. Here’s another way to look at this.
Progressive Enhancement is a design philosophy that states that a more capable browser should have a better experience than one with missing or disabled features. If we “dumbed down” the Web to the lowest common denominator, we’d all be looking at plain text only, since that’s what Lynx can see.
Similarly, some corporate Web users are restricted by their IT department from running Java or JavaScript or even common plug-ins in their browsers as a security measure. A Web site designed to rely heavily on these non-HTML features will be entirely unusable in that case.
One way to avoid these sorts of problems is to build your site like a layer cake. A base layer of HTML and standard CGI elements like form submissions make it possible for anyone to perform the basic functions of your site. In many countries, this basic level of interaction is required by law, as a way to avoid excluding persons with various disabilities — those who may rely on a screen reader or another assistive device, and thus may not be using any of the “eye candy” you labored over.
Once you have this basic functionality in place, you can begin decorating it and adding the bells and whistles that you (or your client) may desire. The Unobtrusive Observer design pattern is one example of this idea — by layering on a fancy JavaScript effect in a way that the content is not crippled by a lack of JavaScript, you are considerate of your entire audience, not just those with the latest and greatest.
Another “cripple” to consider is Internet Explorer, versions 6 and 7 (and probably 8 in at least a few areas). Freeway already includes some sophisticated shims to prop up IE’s more common failings, but there are so many layout features available to Gecko (Firefox, Camino) or WebKit (Chrome, Safari, MobileSafari, Android, iCab, WebOS, OmniWeb) browsers that are simply not on offer in IE, and it’s not clear when or if they will be added.
So what to do about this? One approach is to use sophisticated hacks and work-arounds to “fix” IE. Another is to apply your extra styles in a manner that IE can ignore safely.
One example of this would be columns. Both WebKit and Gecko (v. 3 and up) can render multi-column text. A single DIV of running text can be divided into multiple columns, with a specified gutter or gap between columns, and an optional vertical divider rule to separate these columns visually. By adding a simple bit of CSS style to the HTML box:
#item1
{
-moz-column-count: 2;
-webkit-column-count: 2;
-moz-column-gap: 1em;
-webkit-column-gap: 1em;
-moz-column-rule: 1px solid #CCCCCC;
-webkit-column-rule: 1px solid #CCCCCC;
}
…you get multiple columns in a compatible browser, and one wide column of text in everything else. There’s an Action to automate this: CSS3 Columns so you don’t even have to break a sweat (or a text editor).
If you had used a table (or even worse, a pair of positioned DIVs) to hold the two “columns” of text, then anyone who visited using a screen reader or another assistive device would be stuck trying to figure out where one column ended and the other began. Because of the vagaries of HTML, one column could be separated from another by a whole swath of code related to a different part of the page.
This layout would be considered “broken” if you assumed that every browser should see the same thing. But if you look at it from the point of view that all browsers should see the same content rather than a pixel-perfect replica of the same page, you will see that this approach gives you a tremendous new freedom to design creatively while not dumbing down your layouts or relying on fragile “hacks” to cater to IE.
