No, those sites are HTML5 plus some browser-specific additions, some of which are Chrome-only, some of which are WebKit-only, some of which are IE-only, some of which are Gecko-only, some of which are Firefox-only, etc.
> The sites will also run on other browsers if they > support HTML5
Oh, really? Please try running http://getcrackin.angrybirds.com/ in a non-WebKit browser. The page relies on sniffing for a -webkit CSS property in a way that relies on a bug in WebKit's CSSOM implementation, and if that bug is not present of if that prefixed property is not supported, will just show you a "This game can only be played on Chrome" message and a "Download Chrome" button instead of just letting you play the damn game.
Of course if you change the source of your browser to duplicate the CSSOM bug and pretend to have support for that -webkit property, the game does work (especially well if you also add support for yet another non-standard CSS property, actually).
> it's hardly Google's fault if other browsers do not > support HTML5
It's Google's fault if they push the idea that "Chrome" and "HTML5" are the same thing. It leads to sites like the one linked above and comments like yours....
Insofar as one can talk about "Google" as a monolithic entity anyway. Which is not very much, as evidenced by the quote you give. There are a number of distinct parts of Google that have pretty different goals (e.g. the people doing marketing and bundling deals for Chrome are pretty scummy, the Youtube folks want to build DRM support into HTML, the actual Chrome developers are pretty reasonable for the most part and not exactly always happy with the actions of other parts of Google).
They have in the past, yes. For example, until Microsoft bought Skype, a default Skype install would install Chrome and make it your default browser. If you wanted to avoid that you had to jump through some hoops during the install.
How much money do you think Google paid Skype for that deal?
They have similar deals with Adobe (installing Flash will install Chrome too), some antivirus vendors (Kaspersky, say), and lots of other software distributors.
Welcome the the way business is done in the Googleplex.
> What??? It doesn't run on HTML5 Firefox or IE9?
Nope. It explicitly sniffs for WebKit and refuses to run on other browsers.
> You can get exemptions for just about anything > from Apple if you work with them.
Unless they think of you as a competitor, of course. In which case they will just screw you over.
As a case in point, Opera has repeatedly tried and failed to get an exemption for Opera Mini to ship security updates on a sane schedule in the app store.
> If you frequently need security updates they will > put a mechanism in place
They haven't in the past, and I have seen no indication that they will do so in the future.
The problem is that the policies of the Mac App Store prevent or severely cripple certain kinds of applications.
For example, if your app might need to roll out critical security updates on short notice (e.g. is a web browser or anything else that needs to deal with the internet), you can't do that with the Mac App Store: updates need to be approved by Apple, on whatever schedule they choose to do it on. From what I've seen, the timescale is weeks, whereas critical security updates sometimes need to be pushed out on a timescale of days.
What's going on is that you didn't bother to even read the story, and the summary is misrepresenting the situation. But don't let that stop you from jumping to conclusions!
But they do have _very_ good marketing, and an excellent approach of implementing features just enough to make the simple case work and then claiming support.
Install base amongst Mozilla developers is almost certainly Mac, Linux, Windows in that order, or so claims my anecdotal evidence. And even past that, laptops are predominantly mac, desktops are predominantly Linux.
Percent developed on each is hard to measure. Say a developer writes a patch partially on Mac and partially on Linux and then tests it locally on Windows (including performance profiling and some fixes based on that) before upstreaming. How do you even begin to assign the percentages?;)
According to http://en.wikipedia.org/wiki/Eduardo_Saverin he's lived in Singapore since 2010. That makes it two years, and now he's renouncing his US citizenship. Coincidence? You decide!;)
The Metro API doesn't allow, for example, creating a JIT. So Mozilla _could_ do a browser... if they don't have a JIT and accept various other limitations along those lines.
The only programs allowed to have a JIT in Metro on WinRT are the ones Micorosoft ships (IE10, for example).
What happened with those specs is that Apple proposed the drafts and Apple employees were the original editors (which all makes sense so far)... and then they did absolutely nothing for a while. Completely ignoring feedback mail, not fixing obvious bugs in the text (e.g. the text totally not matching what every browser, including WebKit, implements).
Hard to expedite the standardization process when some participants sandbag.
After a bit of this, new editors got assigned to the drafts, and they're making better progress now.
Note that you should not be confusing "whatever happens to be published under/TR" with "the current state of the spec. The current state of CSS transforms (2d and 3d got folded into a single document) is at http://dev.w3.org/csswg/css3-transforms/ and pretty much no one involved in the working group or the browsers that are implementing these specs pays any attention to what's happening in/TR land.
One last comment: there have in fact been pretty major changes to 2d and 3d transforms since they first appeared, both in terms of browser behavior (esp. around transitions between transforms) and even more in terms of the actual spec (because the initial drafts submitted by Apple didn't even match WebKit's behavior).
Well, sure. And NPAPI was totally proprietary back then.
But then maintenance of the NPAPI spec was moved from Netscape to a setup where multiple browser vendors could cooperate one it, at which point other browsers started adopting it.
If Google gives up sole control of Pepper and stops changing it as the whim hits them, it'd make more sense for other browsers to consider adopting it. As things stand, it'd be complete lunacy for anyone else to adopt Pepper: they'd be completely at Google's mercy in terms of their interaction with plug-ins.
> Pepper is an API which is non-proprietary API. Its > currently Chrome-only
And depends in various ways on Chrome's internal object representation.
Other browsers can implement Pepper just like they could implement ActiveX: by cloning all the underlying functionality. Mozilla even had an ActiveX implementation at one point, for use on corporate intranets; they just never shipped it in the browser by default, because they thought it would be bad for the web.
> Adding functionality using non-standard-but-open >-specification technology when there isn't, at the > time, any standard method
Except in this case there _was_ a standard method (IndexedDB) which Google chose not to use.
That doesn't make them not proprietary. For example, Microsoft or Opera couldn't make use of said implementation even if they wanted to, for legal reasons. And if you think Pepper is documented in enough detail to be implemented interoperably by someone else, I have a bridge you should take a look at.
Worst of all, there's no attempt here to create "standards" (in the sense of people actually agreeing on something and it then being implementable based on the specification). What you have here are code snapshot dumps, with Google retaining complete control over direction of development (which means anyone else who might want to implement them has to get on a treadmill trying to follow whatever random changes Google chooses to make and subject to breakage at Google's whim) and copyright over the only existing implementation, with licensing terms that exclude some competitors.
It's obviously somewhat better than ActiveX, but not by all that much.
Google sort of pushed WebM. They never dropped support for H.264 in Chrome (after repeated promises to do it "soon"), for example.
So more precisely, _some_ parts of Google wanted to have an open standard there. Other parts of Google just wanted a fallback to keep H.264 licensing for them from becoming too onerous. Still others wanted H.264.
As far as getting better by kindness or not, I can't read minds. I can only see actions. And Google's actions are not so hot recently in all sorts of ways, whether that's due to lack of kindness of heart or just due to being forced to adapt to market realities (e.g. Youtube wanting to offer Hollywood video and hence having to deal with DRM in HTML) or because Mr. Brin is having a good day or a bad day. In the end, the actions end up mattering more than the motivations for those actions, in terms of impact on everyone else.
The part where a third party could maintain your computer, where you could easily install third-party software, where there were APIs published for free wasn't "refreshing" and "freedom-loving"?
I think you forget how bad the days of IBM's real dominance were.
In recent years, at least for web standards (CSS comes to mind), Microsoft has actually been very cooperative and helpful. Google has as well. I wouldn't say either one of them is battling open standards there.
On the flip side, Google is pushing a lot more non-standard stuff (in addition to the standards work they do) than Microsoft is right now, for whatever reason.
Google is using its online search monopoly to push its web browser: Chrome is the only thing I've seen advertised on their search front page.
Google does in fact have more open source involvement than Microsoft, agreed.
I wouldn't go so far as to say Google is a "saint" compared to Microsoft; it's much better in some areas and much worse in others. I also wouldn't call them polar opposites. They work together quite well when needed, both for good (CSS specifications) and not-so-good (pushing for adding DRM capabilities to the HTML video tag).
They've tried to (NaCl, Pepper, etc) and are still trying to.
> bundling products to the detriment of their > competition
They've certainly been buying bundling deals such that Chrome is/was bundled with Skype, antivirus software, video codec donwloads, and various other things.
Or for a closer comparison, they've been using their search page as an advertising platform for Chrome. It's the only product that has ever been advertised on the search page, to my knowledge.
> 'reinterpreting' standards such that third party > options no longer interoperate properly
You mean like the WebKit-only gmail offline support using a proposed standard that the W3C decided was not going to become an actual standard because it would be bad for the web?
Google's not as bad at the moment as Microsoft circa 1997, say, but it's way worse than it used to be, and sliding down steadily. And arguably worse than Microsoft is right now.
Uh, yes. Chrome ads have been all over the TV for a few years now. Also all over subway stations in some cities (London comes to mind).
Ad budgets for some of the browsers in the market right now are estimated to be in the high 9 digits to low 10 digits of dollars per year, once you include the value of in-kind advertising and bundling deals. If you exclude those, more like mid-9-digits.
You do realize that the engine overhaul has been ongoing for at least 4 years now, right? It's a pretty big project, is all.
And yes, the important stuff is hard to fix. But most people are in fact way more interested in fixing it than they are in doing UI design (which is _also_ very hard, albeit requiring some slightly different skills).
> How about inventing mechanism so themes and > plugins don't need constant updating
You mean like the one that shipped in Firefox 10 back in January?
But don't mind me. Go back to ignoring the work that's going on and complaining about how no work is going on!
That last part is key. In particular, anyone who redistributes Firefox (Linux distributions come to mind) would be affected. Quite a number of distros have >100,000 users, I bet.
The WebM support is not going anywhere. The discussion is about adding H.264 alongside.
As for the other... there are tons of non-market forces involved. For example, if all browsers have H.264 support, then standards bodies will likely start requiring H.264 to be the codec used for various things (see WebRTC, for an example where this could happen).
Worse yet, once something is in a standard you run into the fact that in many countries following certain standards in certain situations is required by law.
And suddenly there is no market deciding, just edicts from above. And if something comes along that's better than H.264, you're out of luck.
(There are also various practicalities, like the fact that Mozilla couldn't easily provide H.264 for a third or so of their users without shipping non-redistributable code, of course. It's still not clear how that will work out.)
Slashdot Mirror
> those sites are just HTML5,
No, those sites are HTML5 plus some browser-specific additions, some of which are Chrome-only, some of which are WebKit-only, some of which are IE-only, some of which are Gecko-only, some of which are Firefox-only, etc.
> The sites will also run on other browsers if they
> support HTML5
Oh, really? Please try running http://getcrackin.angrybirds.com/ in a non-WebKit browser. The page relies on sniffing for a -webkit CSS property in a way that relies on a bug in WebKit's CSSOM implementation, and if that bug is not present of if that prefixed property is not supported, will just show you a "This game can only be played on Chrome" message and a "Download Chrome" button instead of just letting you play the damn game.
Of course if you change the source of your browser to duplicate the CSSOM bug and pretend to have support for that -webkit property, the game does work (especially well if you also add support for yet another non-standard CSS property, actually).
> it's hardly Google's fault if other browsers do not
> support HTML5
It's Google's fault if they push the idea that "Chrome" and "HTML5" are the same thing. It leads to sites like the one linked above and comments like yours....
Insofar as one can talk about "Google" as a monolithic entity anyway. Which is not very much, as evidenced by the quote you give. There are a number of distinct parts of Google that have pretty different goals (e.g. the people doing marketing and bundling deals for Chrome are pretty scummy, the Youtube folks want to build DRM support into HTML, the actual Chrome developers are pretty reasonable for the most part and not exactly always happy with the actions of other parts of Google).
> How so?They install chrome w/o permission?
They have in the past, yes. For example, until Microsoft bought Skype, a default Skype install would install Chrome and make it your default browser. If you wanted to avoid that you had to jump through some hoops during the install.
How much money do you think Google paid Skype for that deal?
They have similar deals with Adobe (installing Flash will install Chrome too), some antivirus vendors (Kaspersky, say), and lots of other software distributors.
Welcome the the way business is done in the Googleplex.
> What??? It doesn't run on HTML5 Firefox or IE9?
Nope. It explicitly sniffs for WebKit and refuses to run on other browsers.
> What error does it give you?
"Your browser is not supported".
"Without loss" is debatable; for example the set of audio and video formats Chrome handles is larger than the set Chromium handles....
> You can get exemptions for just about anything
> from Apple if you work with them.
Unless they think of you as a competitor, of course. In which case they will just screw you over.
As a case in point, Opera has repeatedly tried and failed to get an exemption for Opera Mini to ship security updates on a sane schedule in the app store.
> If you frequently need security updates they will
> put a mechanism in place
They haven't in the past, and I have seen no indication that they will do so in the future.
The problem is that the policies of the Mac App Store prevent or severely cripple certain kinds of applications.
For example, if your app might need to roll out critical security updates on short notice (e.g. is a web browser or anything else that needs to deal with the internet), you can't do that with the Mac App Store: updates need to be approved by Apple, on whatever schedule they choose to do it on. From what I've seen, the timescale is weeks, whereas critical security updates sometimes need to be pushed out on a timescale of days.
What's going on is that you didn't bother to even read the story, and the summary is misrepresenting the situation. But don't let that stop you from jumping to conclusions!
> and consistent HTML5 adherence.
No, it doesn't mean that at all. It means things like https://bugs.webkit.org/show_bug.cgi?id=78887#c8 (comment 8, in case your browser doesn't scroll down that far).
But they do have _very_ good marketing, and an excellent approach of implementing features just enough to make the simple case work and then claiming support.
Install base amongst Mozilla developers is almost certainly Mac, Linux, Windows in that order, or so claims my anecdotal evidence. And even past that, laptops are predominantly mac, desktops are predominantly Linux.
Percent developed on each is hard to measure. Say a developer writes a patch partially on Mac and partially on Linux and then tests it locally on Windows (including performance profiling and some fixes based on that) before upstreaming. How do you even begin to assign the percentages? ;)
According to http://en.wikipedia.org/wiki/Eduardo_Saverin he's lived in Singapore since 2010. That makes it two years, and now he's renouncing his US citizenship. Coincidence? You decide! ;)
Oh, Mozilla is plenty upset by the iOS limitation, and have said so numerous times in the years since iOS devices started shipping.
The Metro API doesn't allow, for example, creating a JIT. So Mozilla _could_ do a browser... if they don't have a JIT and accept various other limitations along those lines.
The only programs allowed to have a JIT in Metro on WinRT are the ones Micorosoft ships (IE10, for example).
What happened with those specs is that Apple proposed the drafts and Apple employees were the original editors (which all makes sense so far)... and then they did absolutely nothing for a while. Completely ignoring feedback mail, not fixing obvious bugs in the text (e.g. the text totally not matching what every browser, including WebKit, implements).
Hard to expedite the standardization process when some participants sandbag.
After a bit of this, new editors got assigned to the drafts, and they're making better progress now.
Note that you should not be confusing "whatever happens to be published under /TR" with "the current state of the spec. The current state of CSS transforms (2d and 3d got folded into a single document) is at http://dev.w3.org/csswg/css3-transforms/ and pretty much no one involved in the working group or the browsers that are implementing these specs pays any attention to what's happening in /TR land.
One last comment: there have in fact been pretty major changes to 2d and 3d transforms since they first appeared, both in terms of browser behavior (esp. around transitions between transforms) and even more in terms of the actual spec (because the initial drafts submitted by Apple didn't even match WebKit's behavior).
Well, sure. And NPAPI was totally proprietary back then.
But then maintenance of the NPAPI spec was moved from Netscape to a setup where multiple browser vendors could cooperate one it, at which point other browsers started adopting it.
If Google gives up sole control of Pepper and stops changing it as the whim hits them, it'd make more sense for other browsers to consider adopting it. As things stand, it'd be complete lunacy for anyone else to adopt Pepper: they'd be completely at Google's mercy in terms of their interaction with plug-ins.
> Pepper is an API which is non-proprietary API. Its
> currently Chrome-only
And depends in various ways on Chrome's internal object representation.
Other browsers can implement Pepper just like they could implement ActiveX: by cloning all the underlying functionality. Mozilla even had an ActiveX implementation at one point, for use on corporate intranets; they just never shipped it in the browser by default, because they thought it would be bad for the web.
> Adding functionality using non-standard-but-open
>-specification technology when there isn't, at the
> time, any standard method
Except in this case there _was_ a standard method (IndexedDB) which Google chose not to use.
That doesn't make them not proprietary. For example, Microsoft or Opera couldn't make use of said implementation even if they wanted to, for legal reasons. And if you think Pepper is documented in enough detail to be implemented interoperably by someone else, I have a bridge you should take a look at.
Worst of all, there's no attempt here to create "standards" (in the sense of people actually agreeing on something and it then being implementable based on the specification). What you have here are code snapshot dumps, with Google retaining complete control over direction of development (which means anyone else who might want to implement them has to get on a treadmill trying to follow whatever random changes Google chooses to make and subject to breakage at Google's whim) and copyright over the only existing implementation, with licensing terms that exclude some competitors.
It's obviously somewhat better than ActiveX, but not by all that much.
Google sort of pushed WebM. They never dropped support for H.264 in Chrome (after repeated promises to do it "soon"), for example.
So more precisely, _some_ parts of Google wanted to have an open standard there. Other parts of Google just wanted a fallback to keep H.264 licensing for them from becoming too onerous. Still others wanted H.264.
As far as getting better by kindness or not, I can't read minds. I can only see actions. And Google's actions are not so hot recently in all sorts of ways, whether that's due to lack of kindness of heart or just due to being forced to adapt to market realities (e.g. Youtube wanting to offer Hollywood video and hence having to deal with DRM in HTML) or because Mr. Brin is having a good day or a bad day. In the end, the actions end up mattering more than the motivations for those actions, in terms of impact on everyone else.
The part where a third party could maintain your computer, where you could easily install third-party software, where there were APIs published for free wasn't "refreshing" and "freedom-loving"?
I think you forget how bad the days of IBM's real dominance were.
While one might want to deny the existence of the late 80s and early 90s... they really did happen.
In recent years, at least for web standards (CSS comes to mind), Microsoft has actually been very cooperative and helpful. Google has as well. I wouldn't say either one of them is battling open standards there.
On the flip side, Google is pushing a lot more non-standard stuff (in addition to the standards work they do) than Microsoft is right now, for whatever reason.
Google is using its online search monopoly to push its web browser: Chrome is the only thing I've seen advertised on their search front page.
Google does in fact have more open source involvement than Microsoft, agreed.
I wouldn't go so far as to say Google is a "saint" compared to Microsoft; it's much better in some areas and much worse in others. I also wouldn't call them polar opposites. They work together quite well when needed, both for good (CSS specifications) and not-so-good (pushing for adding DRM capabilities to the HTML video tag).
> Are Google enforcing proprietary formats
They've tried to (NaCl, Pepper, etc) and are still trying to.
> bundling products to the detriment of their
> competition
They've certainly been buying bundling deals such that Chrome is/was bundled with Skype, antivirus software, video codec donwloads, and various other things.
Or for a closer comparison, they've been using their search page as an advertising platform for Chrome. It's the only product that has ever been advertised on the search page, to my knowledge.
> 'reinterpreting' standards such that third party
> options no longer interoperate properly
You mean like the WebKit-only gmail offline support using a proposed standard that the W3C decided was not going to become an actual standard because it would be bad for the web?
Google's not as bad at the moment as Microsoft circa 1997, say, but it's way worse than it used to be, and sliding down steadily. And arguably worse than Microsoft is right now.
Uh, yes. Chrome ads have been all over the TV for a few years now. Also all over subway stations in some cities (London comes to mind).
Ad budgets for some of the browsers in the market right now are estimated to be in the high 9 digits to low 10 digits of dollars per year, once you include the value of in-kind advertising and bundling deals. If you exclude those, more like mid-9-digits.
You do realize that the engine overhaul has been ongoing for at least 4 years now, right? It's a pretty big project, is all.
And yes, the important stuff is hard to fix. But most people are in fact way more interested in fixing it than they are in doing UI design (which is _also_ very hard, albeit requiring some slightly different skills).
> How about inventing mechanism so themes and
> plugins don't need constant updating
You mean like the one that shipped in Firefox 10 back in January?
But don't mind me. Go back to ignoring the work that's going on and complaining about how no work is going on!
That last part is key. In particular, anyone who redistributes Firefox (Linux distributions come to mind) would be affected. Quite a number of distros have >100,000 users, I bet.
The WebM support is not going anywhere. The discussion is about adding H.264 alongside.
As for the other... there are tons of non-market forces involved. For example, if all browsers have H.264 support, then standards bodies will likely start requiring H.264 to be the codec used for various things (see WebRTC, for an example where this could happen).
Worse yet, once something is in a standard you run into the fact that in many countries following certain standards in certain situations is required by law.
And suddenly there is no market deciding, just edicts from above. And if something comes along that's better than H.264, you're out of luck.
(There are also various practicalities, like the fact that Mozilla couldn't easily provide H.264 for a third or so of their users without shipping non-redistributable code, of course. It's still not clear how that will work out.)
I totally understand about not having time. If you ever decide you have time for it, just let me know!