HTML 5 is making a huge splash. It’s like web2.0 all over again. I think it’s a massively important moment in the history of the web, but I also think it’s slightly off-center in terms of where the web should be heading.
It’s difficult to say what the web “started out” as, because there was really no single distinct moment of inception. Sir Tim Berners-Lee cobbled together a program to combine already-extant Internet and hypertext systems, but the primary purpose for this ‘web’ of his was to be a document organisation and retrieval system. In fact I think Sir Tim even wanted the web to be editable, so Wikipedia is more or less what he had in mind.
That’s a telling legacy. The web was designed to be an interconnected system of text. Or a decentralised system of text. Or a self-organising system of text. But always: a system of text.
If you examine the HTML elements available to us you can still see that legacy shining through; tables, quotations, headings, paragraphs, lists 1. HTML is designed for text. It took three years before images made it into the HTML spec.
And in the beginning, it was good. “HTML was primarily designed as a language for semantically describing scientific documents” says the HTML5 spec. The web was comprised mostly of text documents with a few figures thrown in. In fact if we look again at Wikipedia, it’s pretty much the poster-child of semantic markup. It uses almost the entire HTML 4 spec; tables, figures, nested headings, lists, paragraphs, italics, quotations. HTML was literally made for this kind of content.
Today’s web has grown far beyond that. In true hackerly style we abused the tools we were given and created web applications on top of that document format (neat!). So some would claim that two kinds of content have emerged on the web – applications and documents.
But web documents still need interfaces, and so I believe documents are actually a subset of applications. For a great example of how documents on the web are really just a specific type of application, check out the NYTimes app2. You might claim that as a special case – they’ve gone ahead and deliberately produced a web application to deliver their documents, but if you take a look at any document on the web and list the features of that document you instantly see that it’s an application. Documents don’t have features, applications do. Web documents have links, comments, scrolling, pages, related content, tags, categories, adverts, metadata. You can click the author’s name to find other content by them. You can share the link with your friends. You can open a print-friendly version. You can copy and paste. You can follow citations within the text.
I don’t think it’s particularly revolutionary to claim that web documents are actually applications. But if I’m right then it doesn’t make any sense for HTML to be a document format any more. Indeed, one of the major motivations behind HTML 5 is that “The main area that has not been adequately addressed by HTML is a vague subject referred to as Web Applications. This specification attempts to rectify this”.
However, reading the spec, it seems as if the authors haven’t accepted or fully understood that documents are a type of application; the phrase “Web applications and documents” is mentioned as though the two are separate things. The spec still feels very much like it’s primarily defining a semantic document format with some neat tools for advanced users who want to create web applications. It needs to become focused on delivering web applications.
Even the web itself sometimes feels as though web apps and documents are diverging in terms of behaviour. You can link to a particular page of a web document, but you often can’t link to a particular part of a web application. You can log in and customise web applications but you often can’t do that with web documents. This is bad and unnecessary, but HTML 5′s reluctance to completely consolidate documents and web applications will only magnify the divergent effect.
Perhaps HTML 5 is now justified in being called a rich document format, what with canvas, video and enhanced form input types. But it should be an application format. Documents are applications. Games are applications. Videos are applications. Almost every piece of content on the web is wrapped inside and delivered by a web application (I only say ‘almost’ because you can direct-link to images and plain text).
The natural question to ask at this point is: “Well, what would an application format look like then?”, but this would take us out of the real world in which the web has evolved. If we were to start from scratch, I can imagine something like XUL being created as a web application format. But we’re not starting from scratch, we’re at a point where the web is pervasive and mature.
As I see it there are 2 problems with trying to create a web application specification in this environment:
1) The interface possibilities on the web are hugely varied. Confining people to a limited set of controls and interface options would be a massive mistake. XUL is designed to produce apps with a consistent look-and-feel. HTML is emphatically not. How could we write a specification for web applications while still maintaining that level of variation?
2) The web is already grown up. We have to work within the framework of JavaScript and DOM. To move away from that would be to make decades of programmers and technologies obsolete, and require entirely new browser technology, just at a time when browser vendors are highly motivated to produce better HTML/JS engines.
So in short – we’re stuck with HTML/JS, and we can’t constrain the interface.
In that environment, the HTML 5 spec does a great job; it provides useful tools for web developers – with web storage, drag and drop, messaging, enhanced input elements and so on – while also extending and embracing the existing framework of the DOM/JS.
In short, I feel that the HTML 5 spec does a great job, and offers exciting new capabilities but just slightly falls short of recognising that the web has always been about delivering applications, and that a focus on the subset of applications which deliver documents is short-sighted. The introduction of elements like ‘nav’ and ‘footer’ seems far too prescriptive, and hints that there are two distinct goals of HTML 5 – spreading semantic markup for documents, and enabling web applications. It won’t be long before it becomes clear that one is greatly more important than the other, and that the two cannot live in harmony.
1 Bizarrely, footnotes weren’t included in any HTML spec, so you have to manually create them using anchors.
2 NYTimes seem to think it’s OK to only give that app to Chrome users. Shame on Google for encouraging this proprietisation of web apps. (But that’s a different blog post…)
#1 by Trung Huynh on February 4, 2011 - 2:57 am
Interesting discussion ! I do agree the web has evolved slowly with HTML5, but even so, the web browsers need time to catch up with it. Hopefully we can see XUL features in HTML6.
#2 by Tikkes on February 5, 2011 - 3:51 am
It was said that with the comming of HTML6 and CSS4 no more hacks would be neccesary in order to support all browsers.
Users would be forced to upgrade their browsers rendering the old one useless.
I’m looking forward to it.
#3 by Vaibhav Kaushal on February 21, 2011 - 11:29 pm
Has been over an year for HTML 5 now being a buzzword. But still, most of the ‘websites’ are not made in or upgraded to HTML 5. Its not just the browsers but also the developers who have to catch up!
#4 by Sault Web Design on April 20, 2011 - 1:34 pm
Very true both are behind right now but everyone is set in their ways and dont want to change, in the next few years it will take over just not today.
#5 by S Jones on September 28, 2011 - 4:33 pm
I agree that there’s a bias toward Documents vs. Applications in the spec. However, most of the web (even web 2.0) is primarily made up of Documents with embedded Applications, not the other way around.
HTML5, like most standards, isn’t predicting or defining the future as much as it is acknowledging the way things are, normalizing how they are done and making those well-worn paths clearer.
The “nav” and “content” and “footer” tags, for example, are (I feel) a really thoughtful, restrained, and minimal way to express the meaningful structure of a web page.
Still, I think HTML6 or whatever’s next needs to tackle the Application side of the equation. You don’t really say what’s needed but I’d say it should be FORMS 2.0 with XAML-like “Application Sheets” for defining layouts, higher-level widgets and dynamic relationships between them (validation, activation, binding to data models, etc.).