When progressive enhancement is worth the effort

The gap between knowing this and actually doing it is where most teams lose ground. Progressive enhancement is not free, and pretending otherwise leads to bad decisions.

Code gets read far more often than it gets written, and usually by someone with less context than the author had. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

When it is worth it

Start with markup that works, then layer behaviour on top. Getting it slightly wrong is survivable. Ignoring it entirely is not. Assume whoever inherits this will have half your context and none of your patience.

When it is not

If nothing downstream depends on it and nobody is complaining, it can wait. This is the sort of thing that compounds, quietly, in both directions.

How to decide

A page that degrades gracefully never fully breaks. In practice this is a scheduling problem more than a technical one. It rarely shows up as a line item, which is exactly why it slips.

In practice

Most development decisions are really maintenance decisions wearing a different hat. Three things worth confirming about progressive enhancement before you move on:

• Someone can say what the current setup is without going to look
• Scripts fail more often than people expect — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If you are not sure where your systems currently stand on this, it takes us about an hour to find out.