HTML beyond HTML5
The day after the W3C unveiled the HTML5 logo, the WHATWG announced that HTML is the new HTML5 and that they will stop using version numbers for their HTML specification.
The main reason for this seems, according to the WHATWG FAQ, to be a desire to fix bugs in the specification and add new features as soon as possible, instead of having to wait for the next version.
That sounds sensible. Fixing bugs and omissions sooner rather than later is good, right? In general it is, of course. However I think it may be a bit problematic in the real world for people who author (“author” is spec writer lingo for front-end developer) websites and want to follow specifications, i.e. validate their markup and have it stay valid according to the rules that were known at the time.
I think we web professionals need a stable specification to refer to, especially when working in teams composed of people in different locations and even different companies. Being able to say “this project uses HTML 4.01 Strict” is very useful since it gives everybody a stable reference that doesn’t change on a daily basis.
Then there’s maintenance. I can predict hearing “Last week this document was valid, but now it isn’t and I haven’t changed anything, why is that?” from some clients. For projects where using valid HTML is a requirement, a versionless HTML specification complicates things.
It seems like keeping validators up-to-date will require more work too. And I wonder what their reports will look like in the future. How about “This document is valid HTML 2012-02-01, has 3 errors when validated against HTML 2012-03-01, and 1 error when validated against HTML 2012-04-01. Do you want to see the results for the next 3 specification revisions?” ;-)
Thankfully the W3C has not moved to a living standards model. For browser vendors the “living standards model” may be desirable, but to me as a developer continuing to refer to the latest HTML specification from the W3C makes more sense since it provides stability. I suppose that means you can have it both ways, which is probably not a bad idea.
That still leaves us with the problem that there is no version indicator in HTML5, which is… well, let’s just say that it’s not exactly my favourite HTML5 feature.
To clarify: I don’t mean to say that the living standards model is all bad or that the snapshot model is perfect. Both have their merits, but my (current) feeling is that the snapshot model is more useful for day-to-day work. Time may very well both prove me wrong and change my mind.