Acid3 doesn't test selector matching while the DOM is changing. What it does test for those 4 points is SVG fonts. Your call on which is more important.
One other note... Webkit and Gecko have different priorities in other ways too: for example, correct behavior of CSS selectors in the face of DOM mutations is a top priority for Gecko (and hence behavior is correctin all the cases I know of) and is not for Webkit (and hence the behavior is not correct in various cases; "for now we will just worry about the common case, since it's a lot trickier to get the second case right" as the Webkit code comments say). There are various other areas in which Webkit is behind Gecko in terms of standards support, and vice versa. They seem to have different future development priorities (e.g. in terms of things like SMIL vs CSS Animations).
It's also not clear which is developing faster, and that aspect is subject to rapid change. I think at this point there are more full-time engineers employed to work on Webkit than on the equivalent parts of Gecko. That may or may not continue to be the case.
Another interesting question, of course, is IE. IE9 has a bigger development team than either Webkit or Gecko, from what I can tell, and they're rapidly working on closing the existing gaps. IE's support for CSS2.1 is better than either Webkit's _or_ Gecko's in my testing (easier to do in some ways because the spec has kept changing so in some cases Webkit/Gecko implement earlier versions). Of course IE has a lot of catching up to do in other areas.
It'll be an interesting next few years all around.
> But the bigger sisue is that WebKit/KHTML is now a better core than Gecko
Based on what metric? It uses more memory, is faster in some cases and slower in others, is easier to hack in some ways. It also just provides a renderer, as opposed to an entire browser. So which is better depends on what you're trying to do and how much effort you want to expend on the non-renderer parts of your app (e.g. to use webkit you have to provide your own http stack and so forth).
If you just want to embed a non-browser HTML renderer that you're going to feed data into, then webkit is better, sure. That's what it's designed for; it's not what Gecko is designed for.
> I've also read (though this may not be quite right) that our large complex brains use > lots of energy, and therefore require greater amounts of food.
Although the human brain represents only 2% of the body weight, it receives 15% of the
cardiac output, 20% of total body oxygen consumption, and 25% of total body glucose
utilization.
(this is footnoted in case you care about the original source).
> The only situation where I would use that junk is if I had a software lock-down at work
That's a nontrivial part of IE6 usage, yes. An interesting plot of IE usage vs time from June 2008 to June 2009, with both moving averages and day-by-day numbers plotted shows that a third of IE6 usage is precisely work-day usage: http://weblogs.mozillazine.org/asa/archives/2009/06/one_year_of_int.html
The scenario CORS is supposed to help with is that of a user being logged into site A (call it The Bank) without site B being able to send certain requests with the user's credentials to site A and read the responses. If site B wants to make requests from their own server, they don't have the user's credentials and will get a 401 or equivalent. If site B wants to make the requests via the browser (which does send credentials with requests), then the request is only sent (in the preflight case) if the right CORS response is received, and the data is not made available to site B unless the right CORS response is received.
Since the browser is the entity here which knows both which trust domain is making the request and which trust domain the request is going to, it needs to be the one which enforces the data not leaking from A to B unless A explicitly wants it to.
> it's not a complete replacement for arbitrary network access
Sure; apps with no security restrictions will always be able to do things that web apps can't do.
> web sites that make the feeds available to the public
They can pretty easily flag those as being available to XHR from anywhere, then. If they really want them to be available that way, of course.
> It also rules out peer-to-peer communication among devices and communication that > doesn't meet the request-response paradigm
To some extent, yes (though some people are trying to fill this gap with Web Sockets, which is a bit of a kludge).
> How would a first-person shooter video game
Probably using various proposed 3d APIs for canvas. But yes, I don't think the web is a good it in all cases, by any means.
> or a video chat application
This people are working on already. In particular, the ability to give (at user discretion) a web app access to the device camera and microphone; then the data can be moved around as desired.
> Guess sooner or later it will become 3D accelerated
Being actively worked on.
> maybe one can have the GPS submit coordinates to the page running the javascript
Possible in Firefox 3.5 and later.
> But shouldn't it still be somewhat limited?
Depends on your phone, obviously. The browser will have to sandbox apps coming from the untrusted web, of course, but a lot of apps don't need much in the way of trust...
> Don't "native non-webrelated apps" have any benefit longer?
I think they do, sure. For one thing, you own the data. This is a problem that still needs to be solved for web apps.
The Web Apps offline storage stuff has been shipping in Gecko since Firefox 3.0, I believe. You can use Zimbra in an offline browser today, compose mails, and it will save them to its local storage area and then send when you go online.
As in, this has been a solved problem for at least a year and a half, and going on two browser major updates now.
Firefox and Fennec already expose accelerometer data to the DOM (via events). There's ongoing work to define APIs for microphone and camera access. File import is done (see File objects in Firefox and the web apps specs); file export is being thought about (some security concerns here). XMLHttpRequest can connect web servers that want to be connected (and define appropriate policies) right now.
So no, the web won't displace existing phone apps tomorrow. In 18 months, who knows.
The last time I profiled some topsites in Firefox, well north of 50% of the CPU time was spent dealing with the Flash ads (as in, 50% of the time the CPU was busy during the pageload the program counter was inside the Flash plugin). Given the typical latency of the ad networks, I'd estimate over 40% of total load time on those sites was taken up by the ads.
> What if the laws of physics aren't the same in all systems?
If you mean not the same in all inertial frames with a given orientation and position (so differing only in velocity), then special relativity goes out the window.
If you mean not the same for all orientations, conservation of angular momentum goes out the window.
If you mean not the same for all positions, conservation of linear momentum goes out the window.
All are possible; if they are observed, then to make meaningful predictions we'd have to know exactly how the laws of physics change as a result of velocity/orientation/position....
There were experimental indications of special relativity (specifically the Michelson-Morley experiment) before the mathematical formalism existed.
So more precisely, there was experimental evidence that the existing theory (waves in an aether) was wrong. Special relativity was created as a theory to fit those experiments. It then made some other predictions in addition to predicting the Michelson-Morley result; various experiments were conducted to test these predictions and they turned out to be correct.
Generally speaking, that's how a scientific theory should work. It should: 1) match existing experimental evidence (otherwise it's clearly wrong) and 2) make testable predictions that we have _not_ tried testing yet. Then we go and test those predictions and the more they turn out to be correct the more convinced we become that a future test will be correct. Which is the point of having a theory at all: predicting what will happen without actually carrying out the experiment.
A problem with the modern high-energy and cosmology theories is that they fall down on item #2 above (specifically our ability to test their predictions). It doesn't help that existing theories (specifically GR and quantum) don't quite fall down on #1 above yet; we're dissatisfied with them because we can think of experiments for which they should give different predictions, hence we know they can't both be right in their current form but we haven't figured out a way to perform said experiments yet. So we don't know whether it's one or the other or both that's wrong, and don't have any indications as to what the right thing should be. We're filling in by generating various theories in the meantime, in the hope that once we can conduct such experiments we can then see which of those theories are more likely to be true (i.e. fit the resulting experimental results). The big hope, in some ways, is to find such a theory that actually makes predictions that somehow turn out to be sanely testable...
Of course underlying all this is a fundamental assumption that there's a mathematical model for the whole setup to start with. That's a meta-theory, of sorts: physical phenomena can be described in mathematical terms. Pretty good experimental support for it so far, as long as one is willing to add new branches of mathematics as needed.;)
JavaScript can be executed in a sandbox (e.g. websites) or not (e.g. an application that embeds SpiderMonkey without any sort of sandboxing). Similar with Java: some Java runs in a sandbox and some doesn't (e.g. one can write Java programs that write various files on disk and execute them in a jvm directly).
Extensions in Firefox are not sandboxed. Perhaps they should be; then they would be significantly more limited in what they can do (both good and bad). For example, a sandboxed extension, for any sane definition of sandboxing, couldn't do some of the things Firebug does, much less Chromebug.
> Where do you get that figure of 200-300k FF nightly users
I believe it comes from the update server (which is basically contacted by nightlies every so often to see if there's an update to the next nightly, just like other builds contact it to see if there's an update). Then you extrapolate from the number of update checks. It's a rough estimate, of course; as are all usage numbers.
And maybe I'm confusing the nightly and beta, of course! If I find the source where I saw the number, I'll comment.
I'm not sure what managed language has to do with this. Firefox extensions are written in a managed language. If your managed language code does something dumb (like taking a string from a web page and acting on it in some way that gives the web page the ability to place data of its choosing on your hard drive), you still lose security-wise...
I just tried this in the Firefox 3.6 beta. Loads in about 3-4 seconds over here. 3.5 takes a lot longer (not sure how long; I got tired of waiting and killed it).
Slashdot Mirror
Acid3 doesn't test selector matching while the DOM is changing. What it does test for those 4 points is SVG fonts. Your call on which is more important.
One other note... Webkit and Gecko have different priorities in other ways too: for example, correct behavior of CSS selectors in the face of DOM mutations is a top priority for Gecko (and hence behavior is correctin all the cases I know of) and is not for Webkit (and hence the behavior is not correct in various cases; "for now we will just worry about the common case, since it's a lot trickier to get the second case right" as the Webkit code comments say). There are various other areas in which Webkit is behind Gecko in terms of standards support, and vice versa. They seem to have different future development priorities (e.g. in terms of things like SMIL vs CSS Animations).
It's also not clear which is developing faster, and that aspect is subject to rapid change. I think at this point there are more full-time engineers employed to work on Webkit than on the equivalent parts of Gecko. That may or may not continue to be the case.
Another interesting question, of course, is IE. IE9 has a bigger development team than either Webkit or Gecko, from what I can tell, and they're rapidly working on closing the existing gaps. IE's support for CSS2.1 is better than either Webkit's _or_ Gecko's in my testing (easier to do in some ways because the spec has kept changing so in some cases Webkit/Gecko implement earlier versions). Of course IE has a lot of catching up to do in other areas.
It'll be an interesting next few years all around.
> But the bigger sisue is that WebKit/KHTML is now a better core than Gecko
Based on what metric? It uses more memory, is faster in some cases and slower in others, is easier to hack in some ways. It also just provides a renderer, as opposed to an entire browser. So which is better depends on what you're trying to do and how much effort you want to expend on the non-renderer parts of your app (e.g. to use webkit you have to provide your own http stack and so forth).
If you just want to embed a non-browser HTML renderer that you're going to feed data into, then webkit is better, sure. That's what it's designed for; it's not what Gecko is designed for.
> I've also read (though this may not be quite right) that our large complex brains use
> lots of energy, and therefore require greater amounts of food.
To cite Wikipedia from http://en.wikipedia.org/wiki/Brain#Brain_energy_consumption :
Although the human brain represents only 2% of the body weight, it receives 15% of the
cardiac output, 20% of total body oxygen consumption, and 25% of total body glucose
utilization.
(this is footnoted in case you care about the original source).
> The only situation where I would use that junk is if I had a software lock-down at work
That's a nontrivial part of IE6 usage, yes. An interesting plot of IE usage vs time from June 2008 to June 2009, with both moving averages and day-by-day numbers plotted shows that a third of IE6 usage is precisely work-day usage: http://weblogs.mozillazine.org/asa/archives/2009/06/one_year_of_int.html
That would be possible if the browser had full control over the HTTP library. Apparently some do not.
The scenario CORS is supposed to help with is that of a user being logged into site A (call it The Bank) without site B being able to send certain requests with the user's credentials to site A and read the responses. If site B wants to make requests from their own server, they don't have the user's credentials and will get a 401 or equivalent. If site B wants to make the requests via the browser (which does send credentials with requests), then the request is only sent (in the preflight case) if the right CORS response is received, and the data is not made available to site B unless the right CORS response is received.
Since the browser is the entity here which knows both which trust domain is making the request and which trust domain the request is going to, it needs to be the one which enforces the data not leaking from A to B unless A explicitly wants it to.
> And restricting XHR using a list of exceptions to a client-side same origin policy isn't
> even secure
It actually is, for non-public resources (ones requiring a login).
> it's not a complete replacement for arbitrary network access
Sure; apps with no security restrictions will always be able to do things that web apps can't do.
> web sites that make the feeds available to the public
They can pretty easily flag those as being available to XHR from anywhere, then. If they really want them to be available that way, of course.
> It also rules out peer-to-peer communication among devices and communication that
> doesn't meet the request-response paradigm
To some extent, yes (though some people are trying to fill this gap with Web Sockets, which is a bit of a kludge).
> How would a first-person shooter video game
Probably using various proposed 3d APIs for canvas. But yes, I don't think the web is a good it in all cases, by any means.
> or a video chat application
This people are working on already. In particular, the ability to give (at user discretion) a web app access to the device camera and microphone; then the data can be moved around as desired.
> Or I could use a traditional POP/SMTP client,
Sure thing, though the equivalent would be closer to an IMAP client with a local cache of the messages.
> Offline email has been a solved problem for over two decades, in fact.
Yes; my point is that the "web application not usable when offline" problem is in fact solved.
> Guess sooner or later it will become 3D accelerated
Being actively worked on.
> maybe one can have the GPS submit coordinates to the page running the javascript
Possible in Firefox 3.5 and later.
> But shouldn't it still be somewhat limited?
Depends on your phone, obviously. The browser will have to sandbox apps coming from the untrusted web, of course, but a lot of apps don't need much in the way of trust...
> Don't "native non-webrelated apps" have any benefit longer?
I think they do, sure. For one thing, you own the data. This is a problem that still needs to be solved for web apps.
> Not to mention offline operation and storage.
The Web Apps offline storage stuff has been shipping in Gecko since Firefox 3.0, I believe. You can use Zimbra in an offline browser today, compose mails, and it will save them to its local storage area and then send when you go online.
As in, this has been a solved problem for at least a year and a half, and going on two browser major updates now.
Firefox and Fennec already expose accelerometer data to the DOM (via events). There's ongoing work to define APIs for microphone and camera access. File import is done (see File objects in Firefox and the web apps specs); file export is being thought about (some security concerns here). XMLHttpRequest can connect web servers that want to be connected (and define appropriate policies) right now.
So no, the web won't displace existing phone apps tomorrow. In 18 months, who knows.
Fennec on the n900 has access to the accelerometer and camera.
Fennec can't run on the iPhone at all (since it includes a JS engine), so the Apple case is pretty irrelevant to it...
I think you're confusing statements made by Asa (a person) with the policy of Mozilla (an organization involving a bunch of people).
My personal take on this is that Asa is speaking or himself here, not for the Mozilla community.
> ECMAScript is client side,
You may be interested in http://en.wikipedia.org/wiki/Server-side_JavaScript
I agree that user-visible ECMAScript is client-side, but user-visible _everything_ is client-side, really.
The last time I profiled some topsites in Firefox, well north of 50% of the CPU time was spent dealing with the Flash ads (as in, 50% of the time the CPU was busy during the pageload the program counter was inside the Flash plugin). Given the typical latency of the ad networks, I'd estimate over 40% of total load time on those sites was taken up by the ads.
> If you mean not the same for all positions, conservation of linear momentum goes out the
> window.
To be clear, that effectively means either Newton's second law (in it's generalized F = dp/dt form) or Newton's third law is wrong.
> What if the laws of physics aren't the same in all systems?
If you mean not the same in all inertial frames with a given orientation and position (so differing only in velocity), then special relativity goes out the window.
If you mean not the same for all orientations, conservation of angular momentum goes out the window.
If you mean not the same for all positions, conservation of linear momentum goes out the window.
All are possible; if they are observed, then to make meaningful predictions we'd have to know exactly how the laws of physics change as a result of velocity/orientation/position....
There were experimental indications of special relativity (specifically the Michelson-Morley experiment) before the mathematical formalism existed.
So more precisely, there was experimental evidence that the existing theory (waves in an aether) was wrong. Special relativity was created as a theory to fit those experiments. It then made some other predictions in addition to predicting the Michelson-Morley result; various experiments were conducted to test these predictions and they turned out to be correct.
Generally speaking, that's how a scientific theory should work. It should: 1) match existing experimental evidence (otherwise it's clearly wrong) and 2) make testable predictions that we have _not_ tried testing yet. Then we go and test those predictions and the more they turn out to be correct the more convinced we become that a future test will be correct. Which is the point of having a theory at all: predicting what will happen without actually carrying out the experiment.
A problem with the modern high-energy and cosmology theories is that they fall down on item #2 above (specifically our ability to test their predictions). It doesn't help that existing theories (specifically GR and quantum) don't quite fall down on #1 above yet; we're dissatisfied with them because we can think of experiments for which they should give different predictions, hence we know they can't both be right in their current form but we haven't figured out a way to perform said experiments yet. So we don't know whether it's one or the other or both that's wrong, and don't have any indications as to what the right thing should be. We're filling in by generating various theories in the meantime, in the hope that once we can conduct such experiments we can then see which of those theories are more likely to be true (i.e. fit the resulting experimental results). The big hope, in some ways, is to find such a theory that actually makes predictions that somehow turn out to be sanely testable...
Of course underlying all this is a fundamental assumption that there's a mathematical model for the whole setup to start with. That's a meta-theory, of sorts: physical phenomena can be described in mathematical terms. Pretty good experimental support for it so far, as long as one is willing to add new branches of mathematics as needed. ;)
JavaScript can be executed in a sandbox (e.g. websites) or not (e.g. an application that embeds SpiderMonkey without any sort of sandboxing). Similar with Java: some Java runs in a sandbox and some doesn't (e.g. one can write Java programs that write various files on disk and execute them in a jvm directly).
Extensions in Firefox are not sandboxed. Perhaps they should be; then they would be significantly more limited in what they can do (both good and bad). For example, a sandboxed extension, for any sane definition of sandboxing, couldn't do some of the things Firebug does, much less Chromebug.
> Where do you get that figure of 200-300k FF nightly users
I believe it comes from the update server (which is basically contacted by nightlies every so often to see if there's an update to the next nightly, just like other builds contact it to see if there's an update). Then you extrapolate from the number of update checks. It's a rough estimate, of course; as are all usage numbers.
And maybe I'm confusing the nightly and beta, of course! If I find the source where I saw the number, I'll comment.
This only works for extensions that don't include binary components.
I'm not sure what managed language has to do with this. Firefox extensions are written in a managed language. If your managed language code does something dumb (like taking a string from a web page and acting on it in some way that gives the web page the ability to place data of its choosing on your hard drive), you still lose security-wise...
I just tried this in the Firefox 3.6 beta. Loads in about 3-4 seconds over here. 3.5 takes a lot longer (not sure how long; I got tired of waiting and killed it).