Five mistakes teams make with progressive enhancement

It comes up on almost every project, usually later than it should. These are the ones we run into repeatedly when we audit progressive enhancement.

Most development decisions are really maintenance decisions wearing a different hat. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

Where it usually goes wrong

• Treating it as a launch task rather than an ongoing one
• Assuming someone else already owns it
• Start with markup that works, then layer behaviour on top
• Scripts fail more often than people expect
• Never checking whether the fix actually worked

A page that degrades gracefully never fully breaks. The cost of getting this wrong is rarely visible on the day it happens. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

Where to go from here

In practice

Code gets read far more often than it gets written, and usually by someone with less context than the author had. Three things worth confirming about progressive enhancement before you move on:

• Someone can say what the current setup is without going to look
• Start with markup that works, then layer behaviour on top — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If any of that sounds like a description of your current setup, it is fixable.