This post does an excellent job of explaining, unintentionally, why the decision to remove version numbers from HTML was a bad idea. There are so many new technologies being worked on and browser vendors all have different priorities on which to put resources on implementing.
Think about if HTML5 had been finalized in 2010, with anything proposed in 2011 or 2012 be considering HTML6 (or HTML5.5 or whatever -- who cares). Wouldn't there be a lot of pressure on browser vendors to support all HTML5 features? As it stands today no one can possible keep up with standardization so instead vendors work on what they think is important -- or cynically what will get them the most recognition.
Removing version numbers simply exposed how HTML evolves explicitly, browser vendors will never be forced to implement a particular web standard, they all have their own agenda and goals, while that may bring problems, this fuzzy concencus is the reason web standards are as ubiquitous as they are, and still evolving at a huge pace.
Putting a version number on a specification and dictating that all vendors must implement it by X date (or what?) is just confusing developers about the chaotic way in which standards are built.
Very few developers are even aware that version numbers were removed so I don't think it's had any real effect on developer confusion. It's probably made it worse. This article complains about WebWorkers which was proposed in 2009 but with the way standards evolve it's hard to know what capabilities it has. Meanwhile Firefox has a solid implementation of CSS calc() but not WebWorkers (which I believe they came up with).
In my experience it has helped reduce confusion, I dont see how it could possibly make it worse, unless you count the confusion as developers begin to realise how the web evolves as 'worse', I dont.
As said, browser vendors are have no governing body that force them to implement exact specifications at exact times, I dont see how putting a version number on html and pretending that they do is anything but confusing.
Version numbers do little to prioritize engineering work. Take CSS 2.1, which still doesn't have 100% conformance by any browser: http://test.csswg.org/suites/css2.1/nightly-unstable/report/... and the CSSWG is now working on many CSS Level 4 specs now...
The demands of application developers are much of what drives feature prioritization inside browser developers. Scores and benchmarks certainly contribute, but it'd temper that a bit.. see the recent Maxthon kerfuffle on how browser's have their feet held to the fire on their scores: http://www.favbrowser.com/maxthon-scams-its-score-in-html5te...
Sorry if you took my comment as the implication that version numbers don't matter; they certainly do. But the relationship between specifications and browsers is complex.. My point is only that putting version numbers (instead of timestamped commits) on a spec doesn't assist browser makers.
Specification test suites are really our greatest hope at early cross-browser compatibility and right now they're not in a great state. See also testthewebforward.org which aims to assist this (and movethewebforward.org which birthed it)
> instead vendors work on what they think is important --
> or cynically what will get them the most recognition.
This was always the case and exactly the reason for the removal of version number.
I am not even sure if any browser has a full implementation of HTML4 (most likely not).
Think about if HTML5 had been finalized in 2010, with anything proposed in 2011 or 2012 be considering HTML6 (or HTML5.5 or whatever -- who cares). Wouldn't there be a lot of pressure on browser vendors to support all HTML5 features? As it stands today no one can possible keep up with standardization so instead vendors work on what they think is important -- or cynically what will get them the most recognition.