4 ms·

> There are no web standards anymore - if Google want to add a feature to Chrome, they just go ahead and do it, forcing the other browser makers to adopt that f

> There are no web standards anymore - if Google want to add a feature to Chrome, they just go ahead and do it, forcing the other browser makers to adopt that feature lest they be left behind in the browser market. Isn't that normal? First you add the feature to your browser, then if people start using it you think about standardizing it. The alternative is to spend a bunch of effort standardizing things nobody wants. If anything, I'd like to see more standards that first require a concrete implementation. I think everyone's been handed a spec that has loads of problems when you actually try to implement it. Look at the 'export' keyword in C++.

duskwuff 10y ago
> If anything, I'd like to see more standards that first require a concrete implementation. This is how the standards process has always worked! Per RFC6410, a proposed standard can't advance to an "Internet Standard" until there are at least two independent working implementations. The W3C has a bad habit of writing "standards" before any code has been written; sometimes even before it's clear that any code should be written. (EmotionML, for example.)
- euyyn 10y ago
  Never heard of EmotionML before. OMG.
pcwalton 10y ago
No, it's not normal. That's how we got things like the awful WebKit gradient syntax that everyone is now being forced to implement for legacy compatibility reasons.
bzbarsky 10y ago
The thing currently considered "normal" at least for Google and Mozilla goes like this: 1) Send an intent to implement to a public mailing list, describing the thing you want to implement and its existing standardization state, if any. 2) Add the feature to your browser, enable it on your nightly/dev/canary/devedition/whatever channels but not release. 3) Get feedback from people trying out the feature on those channels. Explicitly solicit feedback via twitter, conversations at conferences, etc, etc. 4) Write a draft spec, run it by other browser implementors. 5) Send a public intent to ship, indicating what other browser vendors think of the idea, what web developers think of the idea, stability level of the spec, etc. 6) If the relevant people in your org (the API owners for Blink; for Mozilla it's a bit less clear so far) approve, you ship. Step 6 can precede finalized standardization. But it can come after too; in particular the "two implementations" criterion for standardization can be fulfilled by pre-release implementations that are on track to become released.

duskwuff 10y ago

> If anything, I'd like to see more standards that first require a concrete implementation. This is how the standards process has always worked! Per RFC6410, a proposed standard can't advance to an "Internet Standard" until there are at least two independent working implementations. The W3C has a bad habit of writing "standards" before any code has been written; sometimes even before it's clear that any code should be written. (EmotionML, for example.)

euyyn 10y ago
Never heard of EmotionML before. OMG.

pcwalton 10y ago

No, it's not normal. That's how we got things like the awful WebKit gradient syntax that everyone is now being forced to implement for legacy compatibility reasons.

bzbarsky 10y ago

The thing currently considered "normal" at least for Google and Mozilla goes like this: 1) Send an intent to implement to a public mailing list, describing the thing you want to implement and its existing standardization state, if any. 2) Add the feature to your browser, enable it on your nightly/dev/canary/devedition/whatever channels but not release. 3) Get feedback from people trying out the feature on those channels. Explicitly solicit feedback via twitter, conversations at conferences, etc, etc. 4) Write a draft spec, run it by other browser implementors. 5) Send a public intent to ship, indicating what other browser vendors think of the idea, what web developers think of the idea, stability level of the spec, etc. 6) If the relevant people in your org (the API owners for Blink; for Mozilla it's a bit less clear so far) approve, you ship. Step 6 can precede finalized standardization. But it can come after too; in particular the "two implementations" criterion for standardization can be fulfilled by pre-release implementations that are on track to become released.