A List Apart


Illustration by Kevin Cornell

Understanding Progressive Enhancement

Since 1994, the web development community has beaten graceful degradation’s drum. A carry-over from the engineering world, the concept was, at its core, about giving the latest and greatest browsers the full-course meal experience while tossing a few scraps to the sad folk unfortunate enough to be using Netscape 4. It worked, sure, but it didn’t really match Tim Berners-Lee’s original vision for a universally accessible web.

Article Continues Below

About a decade later, several smart folks began to question graceful degradation and found it lacking on many levels. Concerned with content availability, overall accessibility, and mobile browser capabilities, they sought a new way to approach web development—a way that focused on the content and did more than just pay lip service to older devices.

At SXSW in 2003, Steve Champeon and Nick Finck gave a presentation titled “Inclusive Web Design For the Future.” There, they unveiled a blueprint for this new way of approaching web development. Steve also gave it a name: progressive enhancement.

There’s a (subtle) difference

In case you are scratching your head, trying to see how graceful degradation and progressive enhancement differ, I’ll say this: it’s a matter of perspective. Both graceful degradation and progressive enhancement consider how well a site works in a variety of browsers on a variety of devices. The key is where they place their focus and how this affects workflow.

The graceful degradation perspective

Graceful degradation focuses on building the website for the most advanced/capable browsers. Testing in browsers deemed “older” or less capable usually takes place during the last quarter of the development cycle and is often restricted to the previous release of the major browsers (IE, Mozilla, etc.).

Under this paradigm, older browsers are expected to have a poor, but passable experience. Small fixes may be made to accommodate a particular browser. Because they are not the focus, little attention is paid beyond fixing the most egregious errors.

The progressive enhancement perspective

Progressive enhancement focuses on the content. Note the difference: I didn’t even mention browsers.

Content is the reason we create websites to begin with. Some sites disseminate it, some collect it, some request it, some manipulate it, and some even do all of the above, but they all require it. That’s what makes progressive enhancement a more appropriate paradigm. It’s why Yahoo! swiftly adopted it and used it to create their Graded Browser Support strategy.

So how does it work?


The Chocolatey Layers of Progressive Enhancement

Start with your content peanut, marked up in rich, semantic (X)HTML. Coat that content with a layer of rich, creamy CSS. Finally, add JavaScript as the hard candy shell to make a wonderfully tasty treat (and keep it from melting in your hands).

If you’re at all familiar with the web standards movement’s mantra—separation, separation, separation—this makes perfect sense. Web standards-based development has often been likened to a layer cake (or, if you want to get really fancy, a trifle).

I prefer the Peanut M&M analogy, because in it, the layers envelop the content completely, in much the same way our styles and scripts wrap our content.

If you’ll indulge my food analogy a bit longer (I hope I’m not making you hungry), I’ll explain why this approach is better and how the layers interact within this paradigm.

The peanut

Some people like peanuts; in fact, some people prefer peanuts to Peanut M&Ms;. Similarly, some folks (and things like search engine spiders) want just the content.

Then there are folks who can’t handle the chocolate and candy layers on top of the peanut (diabetics, for example). Like them, people on mobile devices or older browsers may not be able to see your pretty design or interact with your slick Ajax-driven interface.

Making sure your markup conveys the greatest level of detail about the content it wraps around is essential to offering a basic experience to these users.

The chocolate coating

Next, you can delicately dip your content into a warm bath of ambrosial CSS—but before you jump to the hard candy shell, there are some additional considerations.

There are folks who love chocolate covered peanuts. These folks are like the middle tier of users who have some level of CSS support, but may not have decent JavaScript support. Or they may work at a company where the IT security folks are more than a little phobic about JavaScript. For them, JavaScript may be disabled entirely.

Whether Goober-inclined or Goober-limited, these folks deserve to be catered to. There are several progressively-enhanced ways to apply styles to your content, and they will be the topic of the second article in this series.

The hard candy shell

Finally, you can introduce JavaScript into the mix. With the rich interaction possibilities it provides, as well as its ability to manipulate and interact with the content and presentation layers, JavaScript really is the ingredient that can pull a site together into an “experience.”

I’m not sure exactly how the hard candy shell is added to an M&M (my guess is that it’s another dip of some sort), but adding JavaScript-based functionality and interactivity to your websites is a breeze when you think progressive enhancement. And, in much the same way as M&Ms; are available in a variety of colors, the JavaScript experience can vary based on the capabilities of the browser or device attempting to use it.

As you probably know, this type of development is called unobtrusive JavaScript. I’ll cover those techniques and practices in the third and final article in this series.

Putting it all together

Developing with progressive enhancement is actually quite simple once you understand the concept and begin putting it into practice; perhaps even simpler than making candy. The next two articles in this series will help you hone your progressive enhancement skills with CSS and JavaScript, and will show you how the philosophy translates into code.

43 Reader Comments

Load Comments