A Response to Thoughts on HTML5

This is a response to Thoughts on HTML5 by Janus Boye over on Medium. You can read this response on Medium as well. At the time of this writing, there is one response to my comment.

I am re-creating it here because I feel strongly that relying on a third-party to house your content is not a long-term solution (you can read more about that in my post Stop Throwing Away Your Content).

The headings below are lifted from the headings in the original post. They are not my words.

First, there’s lock-in

That statement is based on a complete misunderstanding of HTML5 and its relationship to JavaScript (formally ECMAScript, a completely different standard from HTML5). It is then compounded by the further misunderstanding that the variety of third-party frameworks that have popped up have any formal connection to the W3C standard. The only lock-in is related to choosing to not learn the specification.

Second, there is authoring

With the loosened restrictions on HTML syntax, it is easier than ever to make a web page thanks to HTML5. You can also use a WYSIWYG or simple text editor. You can still view source. The HTML you knew is still the same (headings, paragraphs, links). Moving away from tables for layout (and using CSS instead) has made it easier than ever to make a conformant document.

Third, there is programming

Your entire argument is self-contradictory; an editing pass would help. HTML has expanded features around forms validation and added new field types (look, no programming!), or you can rely on JavaScript for a heavier lift. You can also ignore those both completely and do your forms validation on the server. If anything, HTML5 offers more options to avoid programming.

Fourth, there’s bloat

The argument you make about file sizes has nothing to do with HTML5, but images, fonts, and (unnecessary) third-party libraries. None of that is a function of HTML5. The size of the HTML on web pages has stayed pretty constant and decreased on larger sites. Citing Roku’s testimony in its self-serving efforts to create a DRM solution outside of HTML does not make it true.

Fifth, there’s the subject of accessibility

I can tell you know very little about accessibility. I suspect you would think a ramp would make a restaurant accessible, even if it was at a 30 degree angle. Just as there are wrong ways to use good tools, and guidelines for proper use become necessary, WCAG offers similar guidelines. Just as it did for HTML4 (it has existed since 1998, after all). Considering recent editors of HTML5 also work as accessibility professionals, I can assure you accessibility has been baked in from the start. That you cite a company like SiteMorse, which has been thoroughly debunked as lying about its numbers and failing to understand accessibility, is clear indication to me that you genuinely do not understand the claim you are making.

Sixth, the most important reason

What you are talking about is compatibility in the future. Considering that one of the principles of HTML5 is about being backward compatible, yes, a standard web browser will be able to read a page in 20 years. Just like a modern browser can read a web page from 20 years ago (had we gone with XHTML2 that would not be true). An unsupported framework is a real risk, but those have existed for some time and will continue to flourish no matter the HTML version.

What’s the solution?

Your solution of XML and XForms is novel. And ludicrous. Until a web browser chooses to run XForms (Mozilla removed support in version 4), it will go nowhere on the client. As it is, most current XForms implementations run server-side and output HTML. Citing a case where a developer got XForms running on Raspberry Pis with no context (let along to link to more detail) suggests it is a niche solution that likely does not scale outside of that context.

Given that an XML document will fail to render with any minor mistake, it would not be useful for anyone but programmers. XHTML (1 strict or 2) suffer from the same problem, and XHTML2 itself discarded backward compatibility, making them both untenable (at best) platforms for the past and future.

Your sole resource for this article is a man who is not acknowledged in the W3C HTML5 specification (meaning he did not contribute to it) and instead worked on XHTML 2, a specification that died on the vine (its charter was not renewed in 2009).