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.
-
JavaScript took responsibility for behavior, aided by the Document Object Model (DOM) and a variety of APIs for handling device and multimedia interactions.
-
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.
It’s not a completely neat separation – some of CSS feels like behavior, and JavaScript can manipulate presentation, for example, but it certainly took a lot of pieces out of HTML. A few aspects of HTML, notably media inclusion, are still mostly handled at the markup level, but most of them aren’t any longer. Forms and linking are both still defined in HTML itself, but aren’t difficult to implement separately.
When the WHATWG formed, its focus on web application development led it to build a variety of JavaScript tools, which still dominate the HTML5 work. In many ways, ‘HTML5’ has been about adding a few pieces of markup functionality to HTML itself and a tremendous pile of JavaScript APIs to browsers in general.
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.
This means that it’s time to free markup semantics from the demands originally placed on HTML. Markup doesn’t become total anarchy: defined markup syntax, both XML’s stricter version and HTML5’s more forgiving version, is still useful to create a parse tree browsers can decorate with CSS and WAI-ARIA, and then manipulate with JavaScript.
HTML itself is still useful – many people and tools know how to read and write it – but there is less and less reason to let the HTML vocabulary be a cage limiting our possibilities. Polyfills emerged as tools for bringing older browsers up to date with the latest specifications. Best practices for using them are still emerging, but they’ve become a more common implementation in frameworks like AngularJS, making it easy for developers to create markup templates that JavaScript will later manipulate.
(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.
I’m not quite ready to join Matthew Butterick in proposing “that the W3C be disbanded.” The W3C (and WHATWG) are still doing good work developing the supporting infrastructure of CSS, WAI-ARIA, and JavaScript APIs. ECMA-262 continues their work on JavaScript.
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.