Web Standards
The Philosophy of HTML5, Explained
Pave the cowpaths, honor the priority of constituencies, choose pragmatism over purity — the values behind the spec.
Pave the cowpaths, honor the priority of constituencies, choose pragmatism over purity — the values behind the spec.
Every specification is an argument about values dressed up as technical text. HTML5 is unusually explicit about its own. Its authors wrote down a set of design principles, and once you know them, the whole language stops looking like a bag of features and starts looking like a coherent worldview. Three ideas do most of the work: pave the cowpaths, the priority of constituencies, and a stubborn preference for pragmatism over purity.
The phrase comes from campus planning: rather than laying sidewalks where designers wish people would walk, you wait to see the dirt paths people actually wear into the grass, then pave those. Applied to HTML5, it means standardizing what developers already do instead of inventing idealized alternatives they'll ignore.
Don't design for the web you wish existed. Standardize the web that does.
This is why HTML5 blessed conventions that were already widespread. Developers had long used <div class="header">, <div class="nav">, and <div class="footer">; HTML5 studied those worn paths and paved them into <header>, <nav>, and <footer>. The elements weren't dreamed up from first principles — they were harvested from real markup.
When trade-offs collide, HTML5 declares an explicit pecking order for whose interests win:
Read that order carefully, because it's genuinely radical. It says a change that helps users but inconveniences developers should still win. It says browser vendors' convenience yields to authors' needs. And it puts the spec writers below everyone they serve, with abstract elegance ranked beneath every human in the chain. Most of HTML5's stranger-looking decisions make sense the moment you apply this ranking.
The third value is the connective tissue. Again and again, HTML5 chooses the messy solution that works over the clean solution that doesn't. XHTML's draconian error handling was pure and unusable; HTML5's defined error recovery is impure and robust. A theoretically tidy language that broke existing content was rejected for a compatible one that carries decades of cruft.
These principles aren't museum pieces; they still govern how the living standard evolves. A proposed feature is judged by whether it serves users, whether it matches what authors actually do, and whether it can ship without breaking the past. "But that's not pure" carries almost no weight in that room — by design.
The deeper lesson for anyone building anything: know your constituencies and rank them out loud. HTML5's greatest trick wasn't any single tag. It was deciding, in writing, whom the platform is for — and then having the discipline to let that ranking make the hard calls. Purity is cheap. Serving real people, in order, is the hard and honest thing.