HTML5: Less Committees, More Competition!

As the HTML5 fever begins to wear off, I’m starting to see some bad tendencies in the development of the web as a platform. While I am excited for the low-level APIs that are making their way into our browsers (from playing audio to 3D to real-time communication), I hate to see trade-offs being made in favor of things that don’t matter.

Picture of a fish

Semantic HTML Does Not Matter

Let’s fire up the grill for the sacred cow of the web: semantic HTML.

The idea is a noble one: use HTML to describe the meaning of the content and CSS to describe its presentational aspects. Semantics is to presentation as emphasis is to bold. This idea sounds very sensible from an armchair perspective, but it crashes and burns when faced with modern reality.

HTML is a UI rendering engine, not a document markup language. To illustrate, I am not writing this document in HTML, I am writing it in Markdown. Markdown is designed to be semantic (unlike HTML!), to have simple, intuitive syntax, and it’s pretty damn good. HTML is its awkwardly high-level intermediate language. But that’s just documents, in fact the majority of HTML tags are rendering not text, but layouts, buttons, menus! So, in this scary state of affairs, where does one find meaning?

Machines should be extracting meaning from APIs. That’s where the all the tasty raw data is. APIs worry about pleasing the machines so that human interface developers don’t have to. API use is growing very fast and I am psyched to see the information ecosystem that will develop. As demands for complexity grow, the separation of human and machine interface is inevitable. This is a good design decision particularly because it lets us use domain-specific technologies.

If a semantic tag replaces a presentational one and nobody is there to see it, is it still semantic? Okay, blind people might notice. Still, extracting meaning from HTML in this day and age is bad design and piling more bad design on top of it is not the solution. I don’t know what the solution is, but it probably uses an API to serve raw data, has a web app for sighted users and a separate app for blind users. The latter can probably be generated from some sort of spec.

We Don’t Need More Tags

Take form elements. How did we make forms before HTML5?

  1. Begin by using standard <input>.
  2. Beat them with CSS until they look the same in all browsers.
  3. The designer says we need placeholders.
  4. Find a jQuery plugin, integrate it into the form.

With HTML5, this is how we make forms:

  1. Begin by using standard <input>.
  2. Beat them with CSS until they look the same in all browsers.
  3. The designer says we need placeholders.
  4. Use the placeholder tag.
  5. Realize that some browsers hide the placeholder tag when input is focused while some keep it.
  6. Get rid of placeholder tag, find a jQuery plugin and integrate it.

Case in point.

Committee vs. Competition

All of these problems come down to one: the HTML platform is being designed by people who think they know what’s best for you. Which means:

  1. The standards are always playing catch-up with reality
  2. Browsers are always playing catch-up with the standards
  3. The stardards are made to appease everyone, including people you don’t care about

The open-source community can build its own technologies on top of the web platform’s low-level APIs. Did we wait for CSS to implement variables? No, we built an awesome CSS preprocessor. Fast forward 5 years and a browser finally lands (a syntactically abominable) implementation of CSS variables. So spectacularly little and so spectacularly late; there is absolutely no reason to use CSS variables over the vastly superior Sass, Less or Stylus. CSS variables were dead 5 years before they were born.

An Alternative Vision

The web platform is not immune to failure as it competes with mobile app platforms. HTML5 is still catching up with Flash, and some have doubts that it ever will. Things are changing so fast these days, HTML5 is bound to have some solid competition soon. In order to survive, the web platform has to embrace the kind of guys that build Sass and CoffeeScript instead of pretending they don’t exist. How long until “HTML5 is dead”?

Here is my vision of a better future for the web platform:

  1. Deprecate all non-presentational tags, perhaps everything but SVG
  2. Double JavaScript’s speed by replacing it with compatible bytecode X
  3. Deprecate everything (from HTML and CSS) that can be efficiently replicated in X, provide it as a forkable open-source library. This includes but is not limited to: UI elements (previously known as form elements), all typesetting and the vast majority of CSS properties.
  4. Things that can’t be efficiently replicated in X should be provided as low-level APIs (WebGL, canvas etc.).

This should be the extent of the web as a platform. Everything else will be determined by the free market. An insane proposal? Perhaps.

Time will tell.