Progressive enhancement is about failure modes, not frameworks

Overview

Progressive enhancement (PE) is a web design strategy in which a page is built so that its content and essential tasks work in a plain, standards-based baseline — usually semantic HTML — and richer capabilities (CSS layout, JavaScript behavior) are added as independent layers that improve the experience where supported, without being required for the page to function.

The strategy can be stated as a single question: when a layer fails, what still works? Its long-standing rival, graceful degradation (GD), asks the inverse: when a feature is missing, how should the page fail?

Definition and core property

• Progressive enhancement: a floor-first strategy. The designer specifies a baseline every client can meet, then layers capabilities on top.
• Graceful degradation: a ceiling-first strategy. The designer specifies the full experience, then defines fallbacks for clients that fall short.
• Core property of PE: layer independence. Presentation and behavior must be removable without destroying meaning or blocking core tasks.

In practice the two produce similar code in the middle of the stack. The genuine difference is which case was designed first.

Origins

PE was formalized in the early 2000s, and the term is generally credited to developer Steven Champeon, writing amid the aftermath of the browser wars, when support for CSS and JavaScript varied wildly between browsers. Its logic is older: the intended separation of structure, presentation, and behavior, and hypertext's founding promise that a link should work no matter what renders at the other end.

The layered model

A defensible baseline usually means:

• Content present in the initial HTML, not assembled client-side from fragments.
• Real navigation and form controls: href attributes, native inputs, a server endpoint that processes submissions.
• State changes that survive a refresh, or at least a page that still renders after one.
• Focusable, labeled controls that respond to keyboard input, not only pointer events.

The live disagreement

Honor it, because it is real. One camp argues that evergreen browsers and near-universal JavaScript support have made PE obsolete ceremony. The other points to flaky networks, assistive technology, search indexing, and the empirical fact that plain HTML pages from two decades ago still render today.

My read is that the honest version of the dispute is about where failure lands, not about tools. For content-first sites — pages meant to inform and be linked to — the case for designing the floor first is strong, and in my view the burden of argument sits with any page that cannot render its own content. For tools whose entire value is the interaction — a collaborative canvas, a code editor — no quantity of HTML substitutes for the product, and a declared minimum-support policy with honest failure states is a coherent GD position. The recurring mistake is each camp treating the other's context as its own. That is not a call for balance between the positions; it is a call for matching the strategy to the artifact.

Practical checks

• Disable JavaScript: is the content readable and the primary task possible?
• Strip the CSS: does the page retain structure and order?
• Submit a form with client-side validation blocked: does the server respond usefully?
• Navigate by keyboard alone: can a user complete the core task?

Related terms

• Unobtrusive JavaScript — behavior attached to markup rather than embedded in it.
• Semantic HTML — elements chosen for meaning, which gives the baseline its structure.
• Resilience — the general property of functioning under partial failure.
• Support tiering — the practice, sometimes called "cutting the mustard," of grouping browsers into capability levels rather than chasing uniformity.