Progressive Enhancement - Development from the inside-out

Article Index

  1. Introduction / Article Index
  2. Part 1, Content FIRST!
  3. Part 2, Semantic Markup
  4. Part 3, CSS Layout
  5. Part 4, CSS Style and Scripting Enhancement


Progressive enhancement is a powerful way of streamlining site development to put what's actually important -- the content and usability -- front-and-center. Simple fact of the matter is people do NOT actually visit websites for the goofy animations, fancy images you hang around the content, artsy fonts, or other things people hang around the content.

Put simply, it means to start with the lowest common denominator -- the content -- and to add functionality and improvements atop it. That low starting point means that no matter what happens, the page is still at least usable at doing what sites are for, delivering content to users! You start with the content, you let that content dictate what HTML goes around it, you then let that content, HTML and a bit of knowledge about usability dictate your layouts, then and only then do you start worrying about colours and presentational images.

On the next few pages we will go through step by step the typical progressive enhacnement appraoch to site development, but first, I think we need to better cover what it is, and how as a rule of thumb the entire industry is putting the cart before the horse.

Industry Fallacies

The very notion of starting out with content or a reasonable facsimile of content, and then allowing the content to dictate the markup, the markup and devices to dictate the layout, and everything to that point to dictate the extra presentation and scripting enhancements is lost on a lot of people who seem to think that flash is more important than substance. Worse, many people simply don't have substance or content of value, which results in their efforts being akin to dumping a can of shellac on a pile.

Marketing and advertising types in particular are so obsessed with being as flashy and shiny as possible, they are actually alienating users instead of drawing them in! While flashy and shiny used to work on things like billboards and print advertising, the simple fact is things like popups, endless pointless advertisements getting in the way of the content, and other "in your face" hard sell methodology is backfiring.

Laughably, Cracked of all places has a very insightful video on that topic...

Equally at fault in the decline of usability is that artists who have zero knowledge of HTML, CSS, or even accessibility have deluded themselves into thinking they are "designers"; when to be frank they don't know enough about user interaction to be designing but two things... and Jack left town.. The mere notion of dicking around in photoshop drawing goofyball pictures of what a site MIGHT look like is utterly and completely back-assward. It's a broken ignorant methodology that puts the cart before the horse, and invariably leads to bloated, slow loading, inaccessible disasters masquerading as a website.

Any way you look at it, no matter how pretty the result, if it gets in the way of what it is users came to your site to do, it's bad design. That's why pretty much every design I've ever seen that started life as a PSD is utter and complete rubbish that should have been taken around back o' the woodshed and put down like Old Yeller before ever being handed off to someone to try and turn it into code.

Now I'm not saying you can't make it pretty -- I'm just saying that shouldn't be your starting point!

Progressive Enhancement and Graceful Degradation

A lot of people consider these to be two separate things, and I consider that extremely shortsighted. Graceful degradation is an age old term for a device or project that should the fancy bits fail, there's a baseline fallback so that no matter how bad things get, basic services remain up and running. It is a significant part of why HTML was even created, and why CSS and JavaScript are (or at least were) separate specifications.

Progressive enhancement is simply the easiest means by which to provide that functionality. You start out at the simplest -- the CONTENT -- and organize it in a text editor as if HTML didn't even exist. You then go through with HTML marking up that content to say what things ARE, and not what they look like!. If you are choosing your HTML tags based on their default appearance you are choosing the wrong tags for all the wrong reasons. This allows the page to be displayed in a meaningful manner on non-visual user-agents.

Wait, I know that look; what is... a "user-agent"? A user agent is a program or device used to access the content. The most common user agent is colloquially known as a "Web Browser". Browsers are simply visual user agents -- but there are all sorts of different user agents out there. "Screen readers" for example are software that reads the page aloud to you. There are morse devices, braille readers, search engines -- those are all types of user-agents and HTML was created to service ALL of them, NOT just the screen you happen to be seated in front of with your perfect vision! Basically a browser is always a user-agent, but a user-agent isn't always a browser.

Only once you have that baseline do you move on to providing your visual styles, starting first with the layouts, NOT the graphics hung on those layouts.. How can you know what sizes of graphics and what types of colours will work before you know where things will go on all your different layoutS - and yes, that's plural; LAYOUTS. Screen media likely won't want the same layout as print, screens come in all sorts of different sizes so your layout needs to be semi-fluid (variable width) and responsive (different layouts based on width). Not everyone wants the same default font size so your layouts have to adjust to a different default size - since all fonts should be declared in EM when possible, NOT pixels!

Then and only then once you have your base layouts working do you start in with the colours, goofy animations, background and presentational images (if any, thanks CSS3), and scripting enhancements. This puts Photoshop and other such paint programs at the END of the project, not the start!!! ...assuming you end up needing them at all.

By building in that order you are progressively enhancing the page. If it works and is usable at every step along that route, it will by definition "gracefully degrade" when/if those fancy bits you keep adding are missing, broken, or simply blocked. That's usability and accessibility for very little extra effort.

...and it's why I consider most of the people who start out dicking around in Photoshop over what it MIGHT look like to either be ignorant fools or outright scam artists, neither of whom are actually qualified to flap their gums on the subject!


  • elementals.js
    A lightweight JavaScript library focusing on cross browser support, ECMAScript polyfills, and DOM manipulation.
  • eFlipper.js
    An image carousel script using elementals.js
  • eProgress.js
    A JavaScript controllable progress bar using elementals.js. Based on the nProgress project that relies on the much heavier jQuery library.


Browse code samples of people I've helped on various forums. These code snippets, images, and full rewrites of websites date back a decade or more, and are organized by the forum username of who I was helping. You'll find all sorts of oddball bits and pieces in here. You find any of it useful, go ahead, pick up the ball, and run with it.