The problem was that ACID3 ended up testing a bunch of things that ranged from irrelevant to actively bad for the web, so it actually made the web worse in a number of ways.
This considerably soured people on an ACID4, unfortunately.... Getting it to happen will involve finding a way to pick the set of things to test that avoids the mistakes of ACID3.
NaCl is open source but tied to totally undocumented Chrome internals via Pepper, which makes it pretty hard to adopt without adopting Chrome wholesale.
Worse yet, NaCl is tied to particular hardware, which means that if it gets traction on the web the bar for a new hardware platform would become very high (think "ARM would not have been viable if this had happened 15 years ago" high). PNaCl, if/when it starts working would help with that problem, but not the Pepper dependency.
Well, if you think the way the award is being given is not ok.
It's certainly been done with Nobel prizes in the past, including the Peace Prize (admittedly, there are only two instances of people refusing a Nobel of their own volition).
Or note the behavior of the editors of the Transitions and Animations spec drafts (who did nothing for a few years, until editors who were not associated with Apple took over the job).
The WebKit community has many members who deeply care about standards. How much the community overall and the project as a whole care is very variable.
> has an explicit policy of trying to behave like other > browsers where possible
For various values of "possible". e.g. https://bugs.webkit.org/show_bug.cgi?id=36084 is a long-unfixed spec-compat and other-browser-compat issue that's "impossible" to fix because there are Dashboard widgets and such depending on the current WebKit behavior.
> listens to feedback, and fixes bugs.
Unless it's inconvenient to one of Apple or Google to do so, of course.
But yes, generally speaking it's a reasonably run development project, which means it listens to feedback and bugs generally get fixed eventually.
> They are the opposite of IE in those critical > respects.
You must be thinking of IE6 circa 2004 or so, when there was no IE team.
The IE team did quite a bit of listening to feedback and fixing of bugs in the late 2000s, and is doing it again now that it exists again. Of course they're not fixing them in IE6 no more than WebKit is fixing bugs in whatever fork it is Android 2.2 is shipping. But you might want to take a look at IE9 and IE10 sometime if you haven't already.
Actually, the address space is in fact key. The goal is to load a known DLL at a known address in the process address space, not a known address in physical RAM, because process address space is what you can see in the code that you will then try to run that will try to call into the DLL.
So in a 64-bit process, this technique is pretty hard to pull off, since it does in fact rely on address space exhaustion.
For other search engines it depends. For example, Wikipedia has asked that the search through their search plugin keep happening over HTTP for now (see https://bugzilla.mozilla.org/show_bug.cgi?id=758857 ).
I've been using Firefox on Android too, in the "eat my own dogfood" way, and while a lot of sites are fine, some are just completely broken because of all the WebKit-isms.:(
Actually, in a very real sense the engine _does_ belong to the competition. To actually get your code landed in WebKit you have to convince the current project maintainers (mostly Google and Apple) to accept it.
Which means that if you want to do something that Google and Apple don't (both, often!) approve of, you have to maintain it as a separate branch and deal with the merge pain. No different from other projects where you have to collaborate with others, but a lot different from having control over the code as Microsoft does with Trident right now.
Everyone and their mother designing "mobile" sites. For some big names, Google, Disney, Comcast, DirecTV, Flickr will all sniff whether you're on "mobile" and either serve you WebKit-only sites or detect that you're not using WebKit and serve you totally different, mostly unusable, sites than they do to WebKit-based browsers.
You should really try using a non-WebKit browser on Android. It's worse than trying to use a non-IE browser in 2000-2001 or so.
Most applications are not automatically launched when you visit random websites.
In fact, that's the change Mozilla made: they turned on click to play for Java so that it is no longer launched automatically when you visit a site with a java plug-in.
The problem is that as runtimes evolve the compiled format changes. Furthermore, the end result of the compilation depends on the exact processor being used by the user, and at least in SpiderMonkey on things like the location of the Window object in memory.
Not only that, but the final compiled version is unsafe machine code, so a browser couldn't trust a web page to provide it anyway.
So pages wouldn't be able to provide a final compiled version no matter what. They may be able to provide bytecode of some sort, but again the bytecode format browsers use is not fixed (assuming it exists at all; V8 doesn't have a bytecode) and compilation of JS to bytecode would have to be replaced by some sort of bytecode verifier for security reasons, so there may not even be much of a performance win from the switch.
Slashdot Mirror
So by "business" you mean "source of money" as opposed to "useful activity"?
That's a pretty narrow definition.
Where by "nobody" you mean Google and Mozilla and Opera, right?
The problem was that ACID3 ended up testing a bunch of things that ranged from irrelevant to actively bad for the web, so it actually made the web worse in a number of ways.
This considerably soured people on an ACID4, unfortunately.... Getting it to happen will involve finding a way to pick the set of things to test that avoids the mistakes of ACID3.
NaCl is open source but tied to totally undocumented Chrome internals via Pepper, which makes it pretty hard to adopt without adopting Chrome wholesale.
Worse yet, NaCl is tied to particular hardware, which means that if it gets traction on the web the bar for a new hardware platform would become very high (think "ARM would not have been viable if this had happened 15 years ago" high). PNaCl, if/when it starts working would help with that problem, but not the Pepper dependency.
> I mean, why not?
Well, if you think the way the award is being given is not ok.
It's certainly been done with Nobel prizes in the past, including the Peace Prize (admittedly, there are only two instances of people refusing a Nobel of their own volition).
> with an active community that cares about
> standards,
Sometimes. And sometimes not so much. Compare Gecko and WebKit's CSS 2.1 support (based on the official test suite) at http://www.w3.org/Style/CSS/Test/CSS2.1/20110323/reports/results.html for example.
Or note the behavior of the editors of the Transitions and Animations spec drafts (who did nothing for a few years, until editors who were not associated with Apple took over the job).
The WebKit community has many members who deeply care about standards. How much the community overall and the project as a whole care is very variable.
> has an explicit policy of trying to behave like other
> browsers where possible
For various values of "possible". e.g. https://bugs.webkit.org/show_bug.cgi?id=36084 is a long-unfixed spec-compat and other-browser-compat issue that's "impossible" to fix because there are Dashboard widgets and such depending on the current WebKit behavior.
> listens to feedback, and fixes bugs.
Unless it's inconvenient to one of Apple or Google to
do so, of course.
But yes, generally speaking it's a reasonably run development project, which means it listens to feedback and bugs generally get fixed eventually.
> They are the opposite of IE in those critical
> respects.
You must be thinking of IE6 circa 2004 or so, when there was no IE team.
The IE team did quite a bit of listening to feedback and fixing of bugs in the late 2000s, and is doing it again now that it exists again. Of course they're not fixing them in IE6 no more than WebKit is fixing bugs in whatever fork it is Android 2.2 is shipping. But you might want to take a look at IE9 and IE10 sometime if you haven't already.
Actually, the address space is in fact key. The goal is to load a known DLL at a known address in the process address space, not a known address in physical RAM, because process address space is what you can see in the code that you will then try to run that will try to call into the DLL.
So in a 64-bit process, this technique is pretty hard to pull off, since it does in fact rely on address space exhaustion.
Sure. It would just plummet even more if it were an oil heater.
Also about your heating source. Burning natural gas or using steam radiators puts a lot more water in the air than burning oil does.
Mozilla is actively implementing the Web Audio API, for what it's worth.
SSL by default for Google since Firefox 14, back in July 2012. See https://bugzilla.mozilla.org/show_bug.cgi?id=633773
For other search engines it depends. For example, Wikipedia has asked that the search through their search plugin keep happening over HTTP for now (see https://bugzilla.mozilla.org/show_bug.cgi?id=758857 ).
I've been using Firefox on Android too, in the "eat my own dogfood" way, and while a lot of sites are fine, some are just completely broken because of all the WebKit-isms. :(
> I'm betting they would get some people in the team of
> maintainers.
Possibly. It's hard to say with these sorts of things. The question I'd be asking as a Microsoft executive is how risky a play this would be...
You mean Trident?
There's a nonzero chance that they don't own all the rights to all the pieces of it, if they licensed them from somewhere.
But past that, who knows. They might just not be ready for that sort of thing at all on an organizational level yet.
> People ought to know that the prefixed attributes
> are in beta and may change.
That would be true if WebKit didn't explicitly promise to never remove or change them. Which they do. So people assume they can use them with no fear.
> Fortunately none of the vendor-specific extensions
> are anything but minor enhancements,
That's just not true for transforms, where not supporting them makes a page done entirely using positioning via transforms totally unreadable.
Or for animations where an element is display:none or off-screen and then animated in: no CSS animations means you never see the element at all.
Seriously, I suggest using a non-WebKit mobile UA for a bit and seeing just how broken some sites are.
Actually, in a very real sense the engine _does_ belong to the competition. To actually get your code landed in WebKit you have to convince the current project maintainers (mostly Google and Apple) to accept it.
Which means that if you want to do something that Google and Apple don't (both, often!) approve of, you have to maintain it as a separate branch and deal with the merge pain. No different from other projects where you have to collaborate with others, but a lot different from having control over the code as Microsoft does with Trident right now.
Firefox 10 ESR is out of support 6 weeks from now, for what it's worth, with ESR 17 taking over.
Very true what you say about IE, though. It's trying to handle IE8 and lower that people run into problems with.
Everyone and their mother designing "mobile" sites. For some big names, Google, Disney, Comcast, DirecTV, Flickr will all sniff whether you're on "mobile" and either serve you WebKit-only sites or detect that you're not using WebKit and serve you totally different, mostly unusable, sites than they do to WebKit-based browsers.
You should really try using a non-WebKit browser on Android. It's worse than trying to use a non-IE browser in 2000-2001 or so.
A lot of people have problems with this setup, precisely because people end up shipping sites that only work in only one browser.
There is no exposed way to disable updates in Chrome that I know of.
Most applications are not automatically launched when you visit random websites.
In fact, that's the change Mozilla made: they turned on click to play for Java so that it is no longer launched automatically when you visit a site with a java plug-in.
> For the Mozilla team to say there will "never" be a
> 64-bit build for Windows
Which is something no one at Mozilla ever said. But don't bother reading what they actually said, just read the lies lazy reporters spouted instead.
What Benjamin said is that there are no plans to ship a final 64-bit product in the next several months.
HSTS support was added in Firefox 4, a bit over year and a half ago. So wonder no longer!
Multithreading should work fine as long as you use separate JSRuntimes on separate threads.
The problem is that as runtimes evolve the compiled format changes. Furthermore, the end result of the compilation depends on the exact processor being used by the user, and at least in SpiderMonkey on things like the location of the Window object in memory.
Not only that, but the final compiled version is unsafe machine code, so a browser couldn't trust a web page to provide it anyway.
So pages wouldn't be able to provide a final compiled version no matter what. They may be able to provide bytecode of some sort, but again the bytecode format browsers use is not fixed (assuming it exists at all; V8 doesn't have a bytecode) and compilation of JS to bytecode would have to be replaced by some sort of bytecode verifier for security reasons, so there may not even be much of a performance win from the switch.