The most important versions of the HTML standard have merely codified the state of browsers at the time. The other W3C standards remain partially (or incorrectly) unimplemented so they're effectively not standards anyway.

The innovation on the web has always begun with the code -- and always with proprietary solutions. The best of these solutions are eventually implemented by everyone and that becomes the standard. Netscape added images, tables, and plugins. IE added events on all DOM elements, xmlHttpRequest, and so on. Different browsers are now beginning to implement "HTML5" features. When all the browsers reach some level of common usefulness then W3C or WHATWG will fit their standard around what's in common usage and call it HTML5.

Having big committees make big plans has never worked for the web.

Agreed. I like how JWZ put it:

http://jwz.livejournal.com/147024.html?thread=760144#t760144

  What's a "de facto standard?" It's what we call a standard.
  What's a de jure standard?" It's what we call a wish.

HTML5 is a debatable chicken-and-egg; one could argue that the standard came first even though a few parts were implemented by browsers prior. And what about XML? SVG? Most of the examples you give are early innovations made by browsers because the standards committees were weak back then. I kind of feel like you need both (standard + code) for an effective solution on the web. One inevitably has to come before the other, but I don't think it's always code.

"The innovation on the web has always begun with the code -- and always with proprietary solutions."

Minor correction: lots of innovation has taken place in open source implementations first, which aren't proprietary.

That's not quite how it works.

It's more like implementors (who make up most of the working group) create features, prefixed in a clear namespace e.g. -o, -webkit, -moz, etc. and then submit proposals for these features which are reviewed and reviewed, become standardized, and everyone implements the agreed upon solution.

It is absolutely critical that these features go through this open process and are well documented. What you are describing is more akin to the Netscape - IE browser wars, which was terrible.

Yeah, knock up a few skyscrapers and then get an architect to draw some plans. What could possibly go wrong.

Seriously I thought we were trying to do it right this time so that the 'net could move on and browsers could differentiate on features not on whether they bother to implement the standards properly.

I pretty much agree with you, but just to clarify one point that you made: this was an issue in the W3C, not the WHATWG.

The whole reason for the creation of the WHATWG was that the W3C was getting absolutely nowhere with HTML standards (XHTML 2, anyone?) and the browser vendors that were actually still improving browsers and adding features decided to get together to create a separate standards body that would standardize on features that people actually want.

Eventually, the W3C realized that WHATWG was stealing all of their thunder, and agreed to adopt the WHATWG Web Apps 1.0 spec as the basis for HTML5, and agreed to some concessions about a more open process and a somewhat different structure from the usual W3C body that heavily favors big corporations which can devote people full time to creating baroque standards instead of actually implementing anything.

Sadly, it's looking like the W3C group is starting to devolve into the old behaviors that killed it in the first place, with confusing private lists, with decisions being made in face-to-face meetings and teleconferences that favor professional standards people instead of actual implementors and users.

Luckily, the WHATWG still exists, and still retains the option of just going off and doing its own thing again if the W3C gets out of hand. I don't believe that it will come to that, but it can if it needs to.

Just wanted to clarify, since the way you phrased your comment made it sound like this was a WHATWG issue, while in fact it was a W3C issue.