Since the web is the vehicle for the ongoing information revolution (which itself is transforming so many areas of the lives of billions of people all over the globe), it is important that the basic building block of the web – HTML – is up to the task: it must continue to support rapid, exciting, and unpredictable developments in the web. It’s a lot of responsibility. Enter HTML 5.
There is a lot on the current Working Draft, so instead of listing all new features and changes (plenty of other sites do that already) I thought I’d share my thoughts about some of the features instead.
Good stuff in the current Working Draft
The lexer and parsing rules. These are great, even if their true usefulness for “serious” web development might be somewhat limited. Now any syntax error on the HTML code will result in the same final DOM and hence the same base model for rendering the page – so HTML rendering will be consistent (or at least consistently broken) across browsers.
Focus on the DOM. This is closely related with the above point. HTML 5 defines both the syntax of the new language but also the structure of the DOM used internally by the browser (and the rules that DOM must follow). In theory, this should bring about much more cross-browser coherence.
New APIs (drag & drop, offline and storage support, canvas, media control). Each one of these is worthy of it’s own blog post, but here’s the shortest summary possible:
- Offline state and storage support are essential for reliable web applications and can truly bring about the slow death of fat desktop environments (mmmn, I wonder when will Microsoft implement this in IE…)
Removal of presentational elements and attributes. Good riddance. This might actually focus some minds into separating their markup from presentation. Now, if only there was a way to get rid of tables-for-layout as a language feature…
Web sockets. Goodbye polling, hello highly-specialised, highly-efficient web applications. This will put current Comet techniques to shame.
Not quite-so-good stuff
Lots of new arbitrary elements and attributes. This is my pet peeve with HTML 5. What is a sensible new element today might be redundant tomorrow as the patterns of semantic organisation change. Furthermore, there are an incredibly large number of other potential elements that would make much more sense to specific areas of work but aren’t included. So we will get <head> and <article> and <aside> and <datagrid> and another thirty-something (at the last count) new elements and attributes. I believe this is the wrong solution, where we are forcing very specific meanings into the language that will be both useless in a large variety of cases and deprecated in the not-so-far future.
The main issue that developers seem to battle with is how to apply a specific semantic model to the language. By adding new elements with pre-determined semantic meanings we are perhaps solving some of the common problems but have not addressed the root causes of the problem: we need custom semantic models. I believe XML has solved this problem with DTDs and namespacing, but those solutions fail for the web due to complexity.
I am not offering a solution to the above problem, I am simply pointing out that the new tags are the quick solution, not the best one. Maybe we could use something akin to annotations in Java? Anyway, that’s a topic for a later blog post…
Editing API. It’s a good idea, but the current specification amounts to little more than a roughly outlined wishlist of a concept. This is not to bash (hard) work-in-progress, but I don’t think the HTML 5 language itself should be concerned with defining the behaviour of a GUI IDE for itself. This is a big project in its own right.
It’s too big. The current Working Draft looks too much like a huge wishlist, with many features being defined within the spec itself. Smaller specs should be split into their own documents and HTML 5 should simply specify its dependencies on those documents. This includes the rather verbose “common microsyntaxes”, several parsing rules (URLs, content-sniffing), canvas API, etc. Trimming things down should also simplify adoption and allow for a more solid spec. For instance, if a given dependency is not defined solidly enough it should be easier to depend on a simpler/earlier version, or even scrap the dependency altogether in favour of having a well-defined HTML 5 spec.
Web sockets. Yes, I listed this above in the “good stuff” section. It also has the potential to put too much power in the hands of web developers (not always famed with good application design). Seriously, though, the web has flourished on top of the HTTP protocol, and although this feature will probably be a good thing it must be treated cautiously due to introducing a different paradigm for data transmission over the web.
Why isn’t there more buzz?
In any case, this is definitely a worthwhile project which will eventually offer some real benefits to the world of web development even if by itself it will probably not be the driving factor of a great information revolution – that has been with us for almost ten years now.