This is actually the problem with a lot of the W3C standards (I should know I've worked on 3).<p>Often times the working groups identify a problem that needs to be solved, but there isn't a solution. The web moves so fast there is this great desire to bring things together as soon as new trend emerges. However, the point of standards is for a lot of experimentation to have happened so that some consensus about what works and what doesn't can happen.<p>Doug is absolutely right, standards and research don't mix.<p>I believe this is one of the reasons one of the standards I worked on (WCAG 2) took around 8 years to create. Starting WCAG 2 hot on the heels of WCAG 1 meant that the industry hadn't figured out how to do accessibility, for whatever socio-political reasons. As such the 8 years was more the time it took for patterns to emerge as to good practice than it was the working group's inability to understand the problem, or apply appropriate definitions and constraints.
HTML5 seems different than ECMAScript 4 in that it proposes substantial, widely beneficial, updates to HTML that would do the web itself a lot of good.<p>Standardized, yet <i>open</i>, enhancements for the web: video, audio, sockets, cross-window communication, and more. Sure, it's ambitious, but it stands to push the web forward in noticeable ways.<p>If we take IE out of the equation, a lot of HTML5 features have already hit Safari, Firefox, (opera?). The primary drag on HTML5 is IE, but even Microsoft has embraced HTML5 to some extent (it describes HTML5 features in its documentation for IE7/8).
It is strange he proposes a HTML4.2 without any hint of what it actually will contain, except fluffy words like "simplify", "streamline" and so on. This is actually what XHTML and XHTML2 attempted - by means of the draconian error handling all parsing ambiguities would disappear, making parsing much simpler. By eliminating all legacy presentational HTML, the vocabulary would get much simpler and so on.<p>The problem with XHTML was that is was too simple and elegant, and didn't consider the actual state of the web: There are already billions of malformed documents, and they dont go away just because you declare them illegal.<p>HTML5 on the other hand accepts and embraces the actuale state of the web. By declaring rules for how to parse malformed HTML, it attempts to solve the major source of interoperability problems between browsers. But this also requires a much more complex spec.<p>I don't like peddling conspiracy theories, but I have to mention that Crockfords attack at ECMAScript 4 only succeeded because of backing by Microsoft. Microsoft supports Crockfords notion that JavaScript absolutely does not need high-level features like classes, type annotations, packages and so on - we are fine with a minimal language, thank you! While at the same time focusing significant ressources to support C# (a much larger language than ES4) as a client side language through Silverlight.<p>Crockford worked in secret with Microsoft on ECMAScript 3.1 before it went public, and I suspect this announcement means that they are working on a HTML4.2 proposal. And I am pretty sure this HTML4.2 will <i>not</i> cointain features like canvas, audio and video, since these features is a selling point of Silverlight relative to HTML.
Now we are getting somewhere. But, why do we even need a HTML 4.2 or a CSS3? Bundling these standards up into giant documents doesn't do anybody any good. First, we should try writing a separate document for each new feature, standardizing each one individually. Then, browsers will have HTML 4.01 + CSS 2.1 + <canvas> + <video> + CSS opacity + CSS 2009 Selectors + Query Selectors + Cross-Domain XHR.