You forgot SPDY, WebRTC, etc. This is nothing like ActiveX. These are open-source technologies and other browsers are free and invited to implement them. They're trying to push the web forward.
In addition to open specifications, as the parent pointed out, they also have open source reference implementations. At least in the cast of SPDY, support has already landed in Firefox. Characterizing this as equivalent to ActiveX shows an ignorance of either the original browser wars or Google's modus operandus these days.
WebRTC is a real standards-track technology. If you look at the draft you linked, none of the four editors even work for Google.
In the other cases cited - good luck making an independent interoperable implementation just from Google's "spec". The same would go for WebM and Dart.
Uh, the SPDY spec is excellent (and is IETF standards-track). The WebM "spec" might be something of a joke, but the fastest decoder right now is a third-party, independent implementation.
NaCl and Pepper are well documented (NaCl extremely so), it's just that other browser vendors (namely Mozilla) don't like Pepper's chrome-centric design and don't agree that NaCl is a good choice for the web. Dart is still being designed last I heard, but it's in a pretty similar spot; just because no one else will touch it doesn't mean there's not a decent spec for what is finished.
Let me make a point with an example. If Apple were to add a tv-streaming protocol to Safari (and opensource it). Would you consider it Google's duty to also add it to Chrome?
EDIT: I know my example is a bit far fetched, but it had to be something that is not in the interest of google.
No, I wouldn't consider it their duty. OTOH, the last time that Apple promised an open spec protocol (Facetime) I would have expected Google (or someone) to provide a high quality Android implementation. Apple didn't follow through.
I don't personally have a problem with the standards that Google has advocated. Dart is unlikely to succeed, IMO, but I would like to see NativeClient (or something like it) picked up by the other browsers.
Sure they're free and open source. But they aren't STANDARDS. You seem to be unable to look objectively at the situation. While ActiveX was closed source, by extending the web with non standard technology the end result will be the same, open source or not.
> Sure they're free and open source. But they aren't STANDARDS.
So? "Standards" only means that some group has blessed them. In particular, it doesn't imply that you're free to implement them.
What can you do with "standards" that you can't do with those projects, as they currently exist? What can't happen with standards that can happen with those projects?
Remember, no one is obligated to follow or conform to "standards".
Wow, you're just being contrary to be contrary aren't you? While no one is obligated to follow standards, they certainly help adoption. Without standards we wouldn't be able to just buy a consumer electronics device and plug it in to our standardized plug with standardized voltage would we? Standards are part of our daily lives and without them we would not have progressed nearly as far as we have.
Further more, the reason standards are nice here is because a 3rd party is the one who blessed the technology, not the biased producer of the technology. And changes to that standard need to go through the standards body and the producer is not the single owner.
Standards doesn't mean "no innovation". While the electric outlet may be a "standard" devices that use the electricity shouldn't necessarily be "standard".
ie if I want an innovative lamp to plug into my standard electric socket, that is okay.
Standards have a place and so do innovations. If Google is releasing all of their innovations which have broad applicability as open source projects, I see no reason they should slow down so that slow-moving, non-innovating standards bodies can catchup.
> Wow, you're just being contrary to be contrary aren't you?
Not at all. I'm pointing out that they don't have the properties that you're asking for in this case.
> Further more, the reason standards are nice here is because a 3rd party is the one who blessed the technology, not the biased producer of the technology. And changes to that standard need to go through the standards body and the producer is not the single owner.
Suppose that Google submitted all of those projects to a standards body, got them approved, and then made an incompatible change to their implementations. How does their status as a standard matter?
Standards don't appear out of the ether, fully formed and ready to be implemented. Properly developed standards are built precisely the way Google is building them: with a publicly available proposal and a reference implementation in widely used software.
But they are adhering to standards as well, more so than anyone else for that matter, point to an instance where they're not.
Also it takes ages for stuff to get standardized, are you suggesting that no technology should be applicable until it's the standard? I see no issue in introducing new cool tech specially if it's opensource.
I think people complaining about this are upset about the network effect, rather than Chrome adding new features. Say you love Firefox. One day, your favorite website decides to switch entirely to SPDY, and you can't use Firefox anymore. It's natural to blame Google for this, since they invented SPDY and put the client into production. But really, it's that site's developer's fault for using nonstandard features.
This happens all the time; Firefox adds non-standard CSS transforms, Microsoft adds non-standard Javascript functionality, and Apple adds proprietary video codecs to Safari. When your web app depends on these things, you hurt your users. But it's your fault for using nonstandard features; it's not Apple's or Google's or Microsoft's fault for making their browser support them. If this upsets you, consider software in general. To use Facebook, you have to use Facebook. That's nonstandard! To use an Emacs extension, you have to use Emacs. That's nonstandard! And so on.
Google and Mozilla are especially innocent, since Apple and Microsoft can easily steal any features they want from Chrome and Firefox. They're the only ones out in the open, and for that, I think they deserve to try new things for the web. If they stick, the other vendors can easily support the new features.
> It's natural to blame Google for this... [b]ut really, it's that site's developer's fault for using nonstandard features
You talk as if blame is a conserved quantity. Just because it's the developer's fault for doing something, doesn't necessarily mean that it's not Google's fault as well for enabling them to do so.
When Google makes these technologies, they are aware of how they will, or can, be used, and that it may involve some fragmentation of the web. Aware of these consequences, they went ahead and released the technologies anyways. In my mind, that entails them a degree of responsibility for the consequences.
It's also difficult for me to take them at their word when they say "we think this problems an acceptable cost to move the web forward," because they also happen to benefit from this fragmentation. I don't think they're being intentionally duplicitous, I just don't think it's possible for anybody to make fully rational decisions in such a situation.
first you say "One day, your favorite website decides to switch entirely to SPDY, and you can't use Firefox anymore. It's natural to blame Google for this, since they invented SPDY and put the client into production. But really, it's that site's developer's fault for using nonstandard features."
then "Google and Mozilla are especially innocent, since Apple and Microsoft can easily steal any features they want from Chrome and Firefox. They're the only ones out in the open, and for that, I think they deserve to try new things for the web. If they stick, the other vendors can easily support the new features."
How would these features stick, if developers using them are to blame?
It is not automatically easy to use an open source implementation of something just because it is open source. This is a very common misconception. If Google had wanted it to be easy for other browsers to use the open source implementation of NaCl, they would have used the standard NPAPI, not the Pepper API. Instead of being designed for interoperability, NaCl is locked to Pepper, a proprietary Google technology.
The problem is when they run off and code something and implement it in Chrome, and then when design problems are found in it during the standardization process they say "well it's deployed in too many units already to fix now", effectively reducing the pool of outside experts in the standards orgs to a bunch of rubber-stamping copy editors.
I hesitate to point at examples because I like all the people involved and feel it's not worth making look like more than they are. But I do think there is some basis for the sentiment. So if you are interested, you could study the process by which the HTTP Origin header came to not allow double quotes. There will always be a natural tension between those shipping code and a standardization process.
I agree, they do a great job following the standards. I love that. What I don't love is when they break away. That's my whole point - work with the standards body to get your new cool tech introduced. Don't just go rogue and do whatever you want, that's when problems arise.
"Breaking away" as you describe it sounds like innovation to me, and pacing innovation to standard bodies would kill it. I can't think of specifics but surly most of what is considered the standard today was once the experimentation of one company or one lab.
If Microsoft made ActiveX open and easy for other browser manufactures to implement in a cross-platform manner, I would absolutely have been in support of it. They didn't, so I wasn't.
Standards bodies move slowly. Non-standardised innovation across browsers is absolutely to be encouraged, as long as it is done in a manner that allows others to implement that innovation too. This sort of innovation is what helps us decide what is worth being made into a standard.
Maybe not ActiveX, but when Microsoft created XMLHttpRequest in their javascript engine, that ended up being pretty significant and great for how the web works today.
You forgot SPDY, WebRTC, etc. This is nothing like ActiveX. These are open-source technologies and other browsers are free and invited to implement them. They're trying to push the web forward.