Thoughts on HTML5

Throughout the past 2 decades, HTML has been with us as the main building block of an open and accessible web. We use it to create webpages and this page is published in HTML. From its desktop origin (Mac to PC to Unix), the past years has seen an explosion in devices (smartphones, iPads) as well as wide adoption far beyond the original text-only mindset (images, video).

HTML used to be easy and simple. Unfortunately the designers of the latest version, HTML5 released in 2014, made it very complicated. According to Steven Pemberton who previously chaired the W3C Working Group on developing HTML, this is

disastrous for non-programmers as things that used to be easy are no longer easy

This article is based on an on-going conversation I’ve had with Steven over the past year as he has visited J. Boye group meetings and keynoted the J. Boye Philadelphia conference with a keynote provocatively titled HTML5 is the new Flash.

As you probably know, Flash is dead and Youtube dealt the killing blow. I wanted to understand better how bad the impact of HTML5 is and what this might mean to digital leaders using the Web to transform companies and industries.

First, there’s lock-in

HTML5 is a markup language used for structuring and presenting content on the World Wide Web. It is the fifth and current edition of the HTML standard.

HTML5 improved support for multimedia and introduced markup for APIs to write complex web application. The advent of HTML5 was a big part of Apple’s decision not to support the proprietary Adobe Flash format on iPads and iPhones.

As Steven Pemberton explained, HTML5 is great news for programmers as you can do anything you like. With the promise to reduce development time several programming frameworks have flourished. The bad news is that your framework decision locks you in. Effectively you can’t change your framework without starting all over. Unfortunately the big framework decisions tend to made either by your agency or by your programmers and too often without understanding the full impact.

To quote Steven

You are committing yourselves to a path that you cannot get out of.

Do you really want your web development to be at the mercy of a third party deciding if and when they will make enhancements available to your developers?

Second, there is authoring

Writing a webpage used to be easy. In the very early days of the Web, it was a read-write Web, where you could easily author webpages inside the browser.

Without programming skills, you could easily do relatively fancy stuff, incl. navigation dropdown lists. Also if you saw something you liked, you could always view source, get some ideas and easily implement it.

Given the complexity of HTML5, these days are over. Let’s say you just want to create a simple webpage with a list of recommended restaurants. Now it takes a programmer’s mind to author a webpage unless you are turning to proprietary tools.

In other words, today the Web is read-only medium, except if you turn to things like a content management system, a publishing platform like Medium or WordPress, but you can’t easily just author a webpage.

Third, there is programming

It used to be a friendly joke among webmasters that you “did programming in HTML”.

HTML was an easily readable markup language and if you wanted to do more advanced stuff you could resort to CSS or even Javascript, which then enabled you to do more advanced stuff. One example could be checking whether you filled in at least 8 characters in the password field. HTML was not a programming language.

With the advent of HTML5, programming has been added to the mix and people are starting to duplicate stuff in Javascript that you could already do in HTML and CSS without using programming. Here’s a good list of examples where you don’t need Javascript.

I am not against programming and JavaScript has done much good to the Web, but replacing simple, compact, declarative approaches in HTML by complex programming is a step in the wrong direction.

Fourth, there’s bloat

With HTML5, file sizes has quite exploded. You might think that storage is cheap and this has little if any impact, but this is far from the case.

Today, the web page for a single tweet is more than a megabyte, while in comparison an entire news article on The Guardian will come in at around 500 kb or half the size of a single tweet.

Bloat not only means maintenance issues, but more importantly a severe performance impact. When webpages become bigger and grow in filesize, the loading time goes up.

Bloat means slow webpages, which is bad for business.

An example from July 8, 2016 of how HTML5 has failed came in a response from American electronics company Roku to the FCC. To quote:

“The Roku representatives further explained that HTML5 is a bulky and expensive architecture that would require third-party device manufacturers to include additional processing power and memory to support it, even in theirlowest-priced devices.”

Fifth, there’s the subject of accessibility

Web Content Accessibility Guidelines (WCAG) has since its inception and launch had a bit of a bumpy road, and although many claim compliance, and want to adopt, its complexity, time requirements and level of training and support have challenged many. At the same time, accessibility is becoming a legal requirement in many countries, e.g. the United Kingdom.

If HTML5 had been designed to be accessible out-of-the-box, you wouldn’t need to have guidelines, because a webpage would automatically be accessible.

According to Steven Pemberton:

Unfortunately, the HTML5 designers were clueless about accessibility

There are plenty of examples of arguments in the HTML5 mailing lists where accessibility people tried to convince the HTML5 people that they needed to make changes in order to help with accessibility, and the HTML5 people basically refused, claiming they didn’t understand what the problem was.

Today, the problem of accessibility is successfully addressed by vendors such as Siteimprove and Sitemorse.

Sixth, the most important reason

While the W3C with its famous tagline of leading the Web to its full potential has a commendable vision, HTML5 was a step in the wrong direction.

Books printed 100 years ago are still readable, and available in many cases. Will we still be able to read and access website built on HTML5 in just 20 years? Or will all our content by lost to future ages because of a dependence on a Javascript processor or a framework that is no longer available? With the advent of HTML5, the web has stopped being about documents, and started being about programs.

This in turn requires new devices and faster Internet connections. Something which is far from available to all.

What’s the solution?

While we wait for the W3C and the slow moving standards processes, we actually do have some available options.

If you want to built a Web-based application, including handling data from forms, then look up XForms, which is currently the only standardized framework (and therefore available from more than one supplier).

At the XML London conference in June, John Chelsom from City University, London shared a fascinating case study on a health system built for the National Health Service (NHS). The original system had 70 people working on it and it cost £10M to build, with an additional £5/patient hardware costs; and it failed.

So he built a replacement system using XForms and the eXist database. He built the system alone, and got the hardware costs down to under 1p per patient. He is now experimenting running it on Raspberry Pis for even lower costs. The system is already in service at 5 NHS hospitals.

Learn more: