Web Standards
Why Bother With Web Standards?
The unglamorous but genuine business case for standards: cheaper maintenance, wider reach, and future you.
The unglamorous but genuine business case for standards: cheaper maintenance, wider reach, and future you.
Ask a room of developers why web standards matter and you'll get a chorus of virtue: accessibility, semantics, doing it right. All true, and all curiously ineffective at convincing anyone holding a budget. So let's make the argument that actually lands — the one about money, time, and the people who inherit your code.
A web standard is an agreement between the people who write markup and the people who build the engines that render it. When you write to the standard rather than to one browser's quirks, you're buying insurance against every browser you didn't test in — including the ones that don't exist yet. That's the whole trick: you code against the specification, and the vendors have already promised to honor it.
Contrast this with the alternative, which the industry lived through and still has scars from. In the browser-wars era, sites were built for a specific browser and version. When the next version shipped, the site broke. Every release was a maintenance event. Standards turned that recurring cost into a one-time one.
Semantic, valid markup is cheaper to maintain for reasons that have nothing to do with ideology:
<nav> is self-documenting in a way that <div class="nav-wrapper-outer-v2"> never will be.Standards-based markup is the same markup that screen readers understand, that search engines parse, that reader modes reformat, that scrapers and voice assistants and whatever comes next can consume. Every one of those is an audience.
Semantic HTML is accessibility, SEO, and content portability for the price of one — you just have to not throw it away.
The remarkable thing is that the accessible version and the SEO-friendly version and the maintainable version are the same document. You don't build three things. You build one correct thing and get the rest for free. A properly labeled form control helps the screen-reader user and the autofill engine and the QA tester simultaneously.
Standards are not a religion, and treating them as one produces its own waste — hours spent chasing a green validator badge on a document nobody will ever maintain differently for it. The goal isn't purity; it's leverage. Follow the standard where it buys you reach, resilience, and readability, which is nearly everywhere.
So bother with web standards not because a spec author will be disappointed in you, but because the cheapest code to maintain, the widest code to reach, and the safest code to hand off all turn out to be the same code. That's not idealism. That's just the good deal hiding in plain sight.