[anon1385]

>The idea that nobody can do anything cool on the web unless all browsers support it seems like a great way to encourage stagnation.

But that's the entire point of open web standards. If you don't like using a runtime that is the lowest common denominator across all platforms then why are you using the web in the first place?

I really don't understand people who claim to support the web and web standards but then moan about vendor X or Y not implementing this or that. That's the single biggest defining feature of open web standards; things don't happen unless everybody agrees. If you don't like it that individual vendors have veto power over things then you don't like open web standards. If you don't like technology that moves slowly and by consensus then you don't like open web standards. These are the costs of creating a platform that is defined by open standards.

[lmm]

Arguing definitions is a waste of time. How about this: I like published formats that become standards as and when they gain multiple implementations. If you try to standardize first and then implement, you get CSS2 (or, my first example, XHTML2). The web features we use are there because one vendor or another implemented them, experimentally (again I refer you to javascript, or the <img> tag), and they became standards some time after that. For non-web examples consider something like python - at first, the implementation was the spec; as it matured and things like jython and pypy began to be important, the spec took on more of an independent existence.

This is the model that works, and google is trying to continue it. Best of luck to them.

[pcwalton]

> How about this: I like published formats that become standards as and when they gain multiple implementations.

That is how the standards process generally works these days.

> The web features we use are there because one vendor or another implemented them, experimentally (again I refer you to javascript, or the <img> tag), and they became standards some time after that.

That was a long time ago, when there were few browsers and the Web was much smaller. Nowadays, whenever a browser ships anything, content immediately starts relying on it, and it becomes frozen for all time. None of your other examples have billions of pieces of content; the probability that some content starts relying on the random corner cases of whatever you ship is almost certain. That is one of the most important reasons the standards process exists: to allow multiple vendors a seat at the table in order to create something that makes sense, as opposed to sitting down, writing a pile of code, having content depend on the random bugs and corner cases in your implementation, and forcing all other vendors to reverse engineer your code. (Being open source does not make reverse engineering free, and doesn't even make it that much easier: the HTML5 parsing algorithm was reverse engineered from IE6 without looking at the source code.)

> This is the model that works, and google is trying to continue it. Best of luck to them.

It's also what got us quirks mode, the content sniffing algorithm, the gratuitous complexity of HTML5 parsing, marquee, blink, and the incredibly underdocumented and hideously complex tables specification. I could go on.

You're portraying CSS2 as a failure, but CSS2 is actually a great example of something that is implementable by virtue of being standardized. CSS2 only looks bad because you can go to the standard and look at the complexity, but automatic table layout (what we had before) is much worse, being defined by a pile of C++ code that few people in the world know, with corner cases and weirdnesses a mile long. To this day, table layout is essentially implemented by reverse engineering Gecko. As someone who has implemented both features, I much prefer the former.