- Naïve enthusiasm – HTML4 sucks and we are going to fix it!
- Feeling daunted by the scope of the undertaking.
- Frustration by the lack of progress on XHTML 2.0 – it’s all just talk, talk, talk and ever-increasing complexity.
- Questioning the assumptions, benefits and motivations for the change – is HTML 4 really broken, or just mildly annoying? Is it more annoying than many other things we live with just fine? Yes, WHATWG largely captured the frustration, but are they suggesting anything better?
- Indifference. I could use HTML4, or 5 or 55 – it is the information and presentation that matter, not how you encode it.
Over the last month I have been implementing a proof of concept solution using modern web-application stack, and I had to catch up with the current state of HTML, CSS and JavaScript. Let’s say that of all three, I find HTML5 to stand out in a weird way – there is a lot of noise in the Web, yet there is nothing so special about it…
In fact, it looks like HTML 5 and its cute logos have turned into an umbrella term for a set of initiatives, of which the actual evolution of the HTML markup language is one of the least interesting aspects.
So, what does HTML 5 bring over the “legacy” HTML 4 / XHTML 1.1 – let's see:
A bunch of new browser APIs and formal specification for many existing ones. This is the most significant achievement of the WHATWG/W3C work, though I am not very clear why is it billed as part of HTML 5. Even if I use a HTML 4, I can still take advantage of these APIs on the JavaScript side.
Standardization and specification of layout rules and processing models. Get rid of the SGML grammar. Again a very significant improvement, and again not related to the changes in HTML The Language.
Improved semantics with new elements like ,
codifying small part of all possible semantics in somewhat arbitrary ways (i.e. we’ve got “nav”, but what if we need to semantically distinguish between primary and secondary navigation? How is
or
?)
I've heard people talk how semantic markup is important for "serious publications". The fact is that HTML was never a first choice for serious publications, documents are typically mastered in specialized formats like LaTex, DocBook, FrameMaker, DITA , which are compiled to whatever version of HTML and the new semantic elements only force them to change the mappings in their compile scripts.
The bottom line is that while I will gladly make use of the new elements and I do find them nice, the impact that they will have on my output cannot be compared with the impact of CSS3, D3.js or underscore.js (which get much less news exposure).
Native multimedia support with tags like Again, a lot of noise about marginal improvements. We’ve been able to put media on the web since early 2000s – yes, it was relying on non-standard plugins, but that obviously didn’t stop YouTube from becoming multi-billion business. Nice, needed, but not really innovative or game-changing.
Embedding of SVG and MathML. That is nice – one problem I see that both SVG and MathML are monsters of specifications (good that they didn’t throw XForms into the mix) and we would never get to the point where they would be fully supported by all major browsers. On the positive side, the situation is better than during the Browser Wars, as the specs are already published, and we are not trying to standardize as we go. On a more pedantic point, while the embedding functionality is a feature of HTML, it is hardly innovation - most of the actual work is done by the long time existing SVG and MathML specs, so to say it's a feature of HTML is a bit disingenuous.
So, to summarize – HTML5 brings us a lot of standardizing and specifying of what was already there (making them more robust and simpler, but not really game-changing). It is a major milestone for browser implementers, but for content developers it only brings minor improvements and a whole set of arbitrary changes. If we compare this with the improvements in CSS and the Cambrian explosion in the world of JavaScript in fact HTML5 looks fairly dull and pedestrian.
