https://alistapart.com/article/understandingprogressiveenhancement/
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.
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.
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.
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.
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.
Getting into the progressive enhancement mindset is quite simple: just think from the content out. The content forms the solid base on which you layer your style and interactivity. If you’re a candy fan, think of it as a Peanut M&M:
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).