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.
- Previous post: HTML5 logo FAQ updated to add clarification
- Next post: CSS Validator to report vendor-specific extensions as warnings, not errors
Comments are disabled for this post (read why), but if you have spotted an error or have additional info that you think should be in this post, feel free to contact me.
Subscribe / follow
Sponsors
Authentic Jobs
- Lead Digital Designer at Nabzem (Los Angeles, CA, Ca, US)
- Front-End Developer Needed at The Tombras Group (Knoxville, TN, Te, US)
- Web Designer/Web Designer Senior at University of Michigan (Ann Arbor, Mi, Mi, US)
- PHP Developer at 428 Designs
DreamHost web hosting
Use the promo code 456BEREASTREET3 to save USD 20 when you sign up for DreamHost

