7 ms·

"So many web standards advocates will cry foul the moment any vendor tries something out that has not already been standardized." While some misinformed people

"So many web standards advocates will cry foul the moment any vendor tries something out that has not already been standardized." While some misinformed people might make this argument, I don't think you'll find anyone making it at Mozilla or other groups that actually participate in web standards development. We all know that the normal process is to implement first and then standardize. That's what Mozilla has done in the past with features like Geolocation and WebGL, and it's what we're doing today with new work like Audio Data, Game Pad, and Telephony. In fact, the W3C process requires two interoperable implementations before a specification can reach the Recommendation stage. But there's a difference between a standard that is developed in the open, with the opportunity for all parties to provide feedback and influence development, and one that is developed and implemented in secret, and then deployed to production browsers and evangelized to content authors before anyone else has a chance to comment on it -- or even on whether the fundamental approach is a good idea. (And obviously these are two extreme ends of a spectrum, with a lot of gray area between them.) The problem with many of Apple's "contributions" (and some of Google's) is that they never write specs for them or bring them to standards bodies. (This is the case for Aplle's -webkit-text-size-adjust.) In some cases they actively fight efforts to standardize them. (This is the case with Apple's touch events.) Or sometimes they do push specs to standards bodies, but only after a highly complex specification has been fully developed behind closed doors. (Google's Dart, NaCL, and Pepper have this problem to some extent.) That's fine if what they really want is a proprietary ecosystem that works in their own browsers. But if they actually want these efforts to be part of the web, and if they want to be seen as stewards of an open web, then just implementing something is not enough. The web has lots of stakeholders, and the initial implementer needs to find a way to bring them to the table.

haberman 15y ago
mbrubeck and I, who are good friends IRL, just had a spirited discussion about this over IM; I'll just repeat a few of my points here for other readers. :) NaCl was first announced in 2008, along with a research paper and and source code (http://googlecode.blogspot.com/2008/12/native-client-technology-for-running.html http://googlecode.blogspot.com/2008/12/native-client-technol...). The next year Google sponsored the NativeClient Security Contest that awarded prizes to security researchers who could break out of the sandbox. A lot of the design surrounding PNaCl has happened in the open (see http://www.chromium.org/nativeclient/pnacl http://www.chromium.org/nativeclient/pnacl). I don't think it's accurate to say that NaCl was developed behind closed doors. Also, other browser vendors seem to oppose NaCl in principle, and it seems unlikely that any other process Google could have taken to get buy-in would have resulted in other browsers accepting it. I agree that there is a continuum of behavior here; in the NaCl case in particular though, it really seems like Google has done the right thing.
deleted 15y ago
[deleted]
- haberman 15y ago
  I actually agree with that: the point of a standard is to specify something in a way that multiple interoperable implementations can exist. If there is only one implementation, it is extremely difficult to say what behavior should be specified in the standard and what should be left implementation-defined.
cromwellian 15y ago
"Never write specs"? I have to say, that some of the rhetoric from Mozilla seems a bit over the top. Mozilla doesn't seem to have had a problem dumping all kinds of Javascript and CSS features into Firefox over the years not all of it making it into draft spec proposals. And how could NaCL have been done any better? It's been publicly published for years prior to the first shipping implementation. If Mozilla was interested, they could have put in requests for how they'd like to see NaCl and Pepper changed to better fit a Firefox implementation, or even a counter-proposal for running untrusted native code. But I've seen no such proposals, instead, just a blanket refusal to even consider it. I think there's a philosophical difference such that Mozilla isn't really interested in anything that isn't JS based, so suggesting that bringing NaCL to the working groups would have changed anything is somewhat disingenuous. It's kind of like hoping that Republicans would contribute to a National Single Payer healthcare plan design if it had been brought to the right committee. It's a shame really, because proprietary native mobile platforms are hurting the web, and consumers don't really care, they just want fast apps which don't kill their battery or phone performance. Something like NaCL for mobile could preserve the DOM, CSS, browser security model, and other good things about the web, but replace JS with something much more performant for games, and this would go a long way to hedging risk against the proprietary native platforms. I'll take portal NaCl C-code calling into browser APIs and WebGL any day over Obj-C code calling into Cocoa that can only be installed through an app-store. If the Web is to be around for decades more, the religion over programming languages needs to give way to polyglotism. As on Dart, the language was released at version 0.1. The grammar isn't all that complex, the library is minimalist. It came with a early spec and source. It is not a "fully developed" specification. No one designs language grammars by committee. Languages are highly personal and opinionated. Usually one or two people design the overall structure of the language privately, and then release an initial spec, and it evolves from there. When Mozilla developed Rust, the first time most of the web heard of it was Graydon dumping a gigantic codebomb into GitHub and it being covered on Lambda-the-Ultimate. Which I think is perfectly find, but let's try and be a little level headed and fair, and not arrogantly think that what Mozilla does is uniquely better than what others are doing. (I speak only for myself and I do not work on Dart, NaCl, nor Chrome)
- haberman 15y ago

haberman 15y ago

mbrubeck and I, who are good friends IRL, just had a spirited discussion about this over IM; I'll just repeat a few of my points here for other readers. :) NaCl was first announced in 2008, along with a research paper and and source code (http://googlecode.blogspot.com/2008/12/native-client-technology-for-running.html http://googlecode.blogspot.com/2008/12/native-client-technol...). The next year Google sponsored the NativeClient Security Contest that awarded prizes to security researchers who could break out of the sandbox. A lot of the design surrounding PNaCl has happened in the open (see http://www.chromium.org/nativeclient/pnacl http://www.chromium.org/nativeclient/pnacl). I don't think it's accurate to say that NaCl was developed behind closed doors. Also, other browser vendors seem to oppose NaCl in principle, and it seems unlikely that any other process Google could have taken to get buy-in would have resulted in other browsers accepting it. I agree that there is a continuum of behavior here; in the NaCl case in particular though, it really seems like Google has done the right thing.

deleted 15y ago

[deleted]

haberman 15y ago
I actually agree with that: the point of a standard is to specify something in a way that multiple interoperable implementations can exist. If there is only one implementation, it is extremely difficult to say what behavior should be specified in the standard and what should be left implementation-defined.

cromwellian 15y ago

"Never write specs"? I have to say, that some of the rhetoric from Mozilla seems a bit over the top. Mozilla doesn't seem to have had a problem dumping all kinds of Javascript and CSS features into Firefox over the years not all of it making it into draft spec proposals. And how could NaCL have been done any better? It's been publicly published for years prior to the first shipping implementation. If Mozilla was interested, they could have put in requests for how they'd like to see NaCl and Pepper changed to better fit a Firefox implementation, or even a counter-proposal for running untrusted native code. But I've seen no such proposals, instead, just a blanket refusal to even consider it. I think there's a philosophical difference such that Mozilla isn't really interested in anything that isn't JS based, so suggesting that bringing NaCL to the working groups would have changed anything is somewhat disingenuous. It's kind of like hoping that Republicans would contribute to a National Single Payer healthcare plan design if it had been brought to the right committee. It's a shame really, because proprietary native mobile platforms are hurting the web, and consumers don't really care, they just want fast apps which don't kill their battery or phone performance. Something like NaCL for mobile could preserve the DOM, CSS, browser security model, and other good things about the web, but replace JS with something much more performant for games, and this would go a long way to hedging risk against the proprietary native platforms. I'll take portal NaCl C-code calling into browser APIs and WebGL any day over Obj-C code calling into Cocoa that can only be installed through an app-store. If the Web is to be around for decades more, the religion over programming languages needs to give way to polyglotism. As on Dart, the language was released at version 0.1. The grammar isn't all that complex, the library is minimalist. It came with a early spec and source. It is not a "fully developed" specification. No one designs language grammars by committee. Languages are highly personal and opinionated. Usually one or two people design the overall structure of the language privately, and then release an initial spec, and it evolves from there. When Mozilla developed Rust, the first time most of the web heard of it was Graydon dumping a gigantic codebomb into GitHub and it being covered on Lambda-the-Ultimate. Which I think is perfectly find, but let's try and be a little level headed and fair, and not arrogantly think that what Mozilla does is uniquely better than what others are doing. (I speak only for myself and I do not work on Dart, NaCl, nor Chrome)

haberman 15y ago