[pcwalton]

> Is it unrelated, or is your argument that if they do it this way, it's somehow now "open" and not "proprietary"? Because if so, i struggle to see why that would be the case :)

Absolutely. If the goal is to create a open, multi-vendor implementation of some feature, then the right way to go about it is to (a) implement it behind a feature flag; (b) present it for standardization; (c) take feedback into account during the process, making changes as necessary; (d) ship it to stable and remove the flag once consensus emerges. Even better if multiple vendors do (a) at the same time, but it's not strictly necessary.

The reason why the flag in step (a) is so important is that it makes step (c) possible. Otherwise, there's a very real risk that content will come to depend on the quirks of your first implementation, making it impossible to take other parties' feedback into account. If you just ship to stable right away, you're running the risk of making the platform depend on a proprietary feature.

The reason why doing (a) before (b) is important is that it prevents unimplementable features and mistakes that only become apparent once implementation happens from being standardized. It also allows users of the feature, not just the folks who implement the platform, to take part in the process.

This process is really the only one I know of for popular multi-vendor platforms that both prevents proprietary features from being locked in and avoids the problems of design-by-committee. That's why both Blink and Gecko have adopted it (and Blink is definitely to be commended for following it).