Why XHTML?

There was a moment, roughly at the turn of the millennium, when serious web authors decided the answer to a sloppy medium was discipline. That discipline had a name and a doctype, and the name was XHTML. To write it was to join a small, slightly self-satisfied club of people who closed every tag, quoted every attribute, and lowercased everything as if untidiness were a moral failing. It was, and I mean this fondly, a wonderful thing to believe in.

The appeal of a machine that refuses to guess

XHTML's promise was that markup would be well-formed in the strict XML sense. Every element opened would be closed. Every attribute would be quoted. The document would be a clean tree with no ambiguity, parseable by anything that could parse XML, transformable, queryable, predictable. The infamous incentive was draconian error handling: serve a page as real XML with a single unclosed tag and the browser would refuse to render it, throwing a yellow screen of parse-error shame.

To a certain temperament this was intoxicating. No forgiveness meant no ambiguity. No ambiguity meant your document was correct, verifiably, the way a program compiles or does not. After years of browsers papering over mistakes, here was a contract that meant something.

Strictness felt like professionalism. If the machine would not tolerate your sloppiness, neither would you.

Why it did not conquer the world

The trouble was arithmetic. The web ran on user-generated content, ad scripts, CMS templates, and copy-paste, and any one stray ampersand could take down an entire page. Almost nobody actually served XHTML with the strict XML media type; they served it as HTML, which meant browsers applied the same forgiving parser as always and the vaunted rigor was theatre. You got the ceremony of closing your <br /> tags without the guarantee that made closing them matter.

Meanwhile HTML5 arrived with a different philosophy: define the forgiveness precisely instead of forbidding the mistakes. The market chose resilience over purity, and honestly, for a network of a billion authors, that was the correct choice.

What we kept, what we let go

XHTML lost the war and won the peace. The habits it drilled into a generation of authors quietly became best practice, absorbed into HTML5's more relaxed body:

• Kept: lowercase element and attribute names, quoted attribute values, explicit closing of container elements, one root of well-nested structure, and the general conviction that markup is a data structure deserving care.
• Kept: the idea that a document should be valid, that running it through a validator is a normal professional act and not paranoia.
• Let go: the self-closing slash as a requirement, the XML declaration, the namespace ceremony, and above all the belief that a single error should punish the reader for the author's mistake.

The deep lesson survives the syntax. XHTML taught us to treat markup as something with rules worth honoring, then HTML5 taught us that rules exist to serve readers, not to flatter authors. Write your tags as if XHTML were still watching. Let your parser be as forgiving as HTML5 allows. That combination, discipline in the hand and generosity in the machine, is most of what good markup is.