When HTML first appeared, it offered a coherent if limited vocabulary for sharing content on the newly created World Wide Web. Today, after HTML has handed off most of its actual work to other specifications, it’s time to stop worrying about this central core and let developers choose their own markup vocabularies and processing.
When the W3C first formed, it formed around HTML, the core standard of content on the Web, defining the structure, appearance, and behavior of content. Over the next few years, however, it became clear that HTML was doing too much, and the W3C and other groups refactored appearance, behavior, and many semantics into separate specifications:
Cascading Style Sheets (CSS) took responsibility for presentation and layout.
WAI-ARIA took responsibility for accessibility semantics, ensuring that content remained available to a broad audience even if developers pushed the current boundaries of markup.
Browsers still need a lot of work to achieve the visions developers have for a unified distributed application platform, but HTML itself carries less and less of that burden. The former flagship spec may be what comes to mind first when people say “web development,” but the reality is that it has been hollowed out. The heavy lifting happens in the other specifications.
(Update: I should have mentioned the Web Components spec, which will simplify this work.)
A stronger case for polyfills, though it was actually meant to argue for adding an element to the standard, comes from last year’s picture element saga. The Responsive Images Community Group developed a specification and implemented it (twice) with polyfills. Those developers weren’t happy when the W3C and WHATWG didn’t seem interested – conversations continue – but from my perspective they’d already done great work in creating the polyfills.
Changing the focus away from markup standards is difficult. The Web Standards Project spent a decade or so (with some of my help) evangelizing the need for web standards, and disbanded recently in the face of success. The message that web tools need to be designed by a central organization is, for better or worse, deeply ingrained, but it’s time for markup to fall out of that story.
It is well past time, though, for the W3C and the browser vendors to stop talking as if they constrain the markup developers can use and focus instead on the many things they can do to make the browsers supporting that markup processing more capable. HTML’s legacy vocabulary is a great foundation on which developers can build their own toolsets. The Web will benefit, however, from letting developers solve their information problems in their own ways, rather than trying to stuff too many things into a single vocabulary.
It’s hard to stop pursuing your greatest successes, even when they’ve been overshadowed by your other work. It’s time, though.
And if it’s too hard to stop standardizing, perhaps shifting the model, so that standards only codify work already done in polyfills, is an option. Even if centralized markup standards have benefits, let’s evolve them rather than design them.