3 ms·
In Google's defense, and basically because I like this particular feature, I have to point out the obvious ... most new browser features happen before and not a
by bad_user 7y ago
In Google's defense, and basically because I like this particular feature, I have to point out the obvious ... most new browser features happen before and not after standardization.
The standardization process is meant for reaching agreement among browser makers and to provide clear specs for those features. But it isn't meant for exploration.
That has always been the case. Even Mozilla does it. And if not, then you can't really get the browser vendors to agree on mostly anything a priori, without market validation.
Standardization works as a refinement of already existing work. E.g. Google came with NaCL/PNaCL which was basically their own ActiveX, Mozilla came with Asm.js in response and the end result was Web Assembly, which is objectively better than both and that wouldn't have happened without that prior art.
The W3C doesn't guard what gets implemented in browsers. It never did. And if browser makers willingly participate in the standardization process, we should thank them, because they can always stop doing it. Because really, retreating from the W3C would mean absolutely nothing for computer illiterate people.
- joshuamorton 7y agoTo elaborate, the process for standardizing browser features today is whatwg managed, not w3c. And it's basically "write a proposal, solicit feedback, implement the feature in one browser, and if it's ever implemented in 3 browsers it's part of the standard".
- SahAssar 7y agoWHATWG is mostly HTML and DOM/browser api:s, ECMAscript is by TC39, CSS is still in W3C, URI schemes (which this is about) are in W3C, as seen in this draft being hosted by WICG, which as far as I can tell is a W3C group.