Web Standards
Web Standards and Error Handling
HTML5's quietest revolution wasn't a new tag — it was finally specifying what browsers do when things go wrong.
HTML5's quietest revolution wasn't a new tag — it was finally specifying what browsers do when things go wrong.
Ask someone what HTML5 introduced and you'll hear about <video>, <canvas>, and the semantic elements. All real, all useful, and all less important than the change nobody puts on the highlight reel: HTML5 defined error handling. For the first time, the specification described exactly what a browser must do with broken input. It sounds like a footnote. It was the foundation everything else stands on.
Before HTML5, the specs told browsers what to do with correct markup and fell silent on the rest. But the web is overwhelmingly incorrect markup — mismatched tags, impossible nesting, missing elements. Each browser filled the silence with its own recovery logic. Those logics differed. That difference, multiplied across millions of malformed pages, was a primary engine of the cross-browser bugs that defined an era.
The problem was never that pages had errors. The problem was that every browser disagreed about the errors.
A missing end tag might close one element in one browser and a different element in another, producing two different DOM trees from the same bytes. Your CSS selector then matched in one and not the other. You'd spend the afternoon adding browser hacks to paper over a disagreement the specification had simply declined to resolve.
HTML5's parsing section did something previous specs considered out of scope: it made error recovery normative. Given any input at all, the algorithm dictates the exact resulting tree. Two conforming browsers fed identical broken markup must now produce identical results.
The payoff is that invalid markup stops being a source of divergence. It's still invalid — you should still fix it — but it fails the same way everywhere. Consider a classic misnesting:
<b>bold <i>bold-italic</b> italic</i>The tags overlap illegally. Pre-HTML5, the resulting tree was anyone's guess and varied by engine. Post-HTML5, the parser's "adoption agency algorithm" specifies precisely how to untangle it, and every conforming browser untangles it the same way.
There's a philosophical fork here worth noticing. One approach — XML's — is to forbid errors: encounter malformed input, refuse to render, show a parse error. Clean in theory, catastrophic on a human-authored web where one stray character would blank the page.
HTML5 chose the other fork: define errors instead of forbidding them. Accept anything, but process it deterministically. This is a more mature engineering stance:
The principle travels well beyond HTML. Any system that consumes messy real-world input faces the same fork: forbid imperfection and be brittle, or define your behavior under imperfection and be robust. HTML5 picked robustness and wrote it down, and in doing so it quietly ended one of the ugliest chapters in front-end history. Not with a flashy new tag — with a rulebook for going wrong.