Every single one of those known issues is blocking1.9- and firefox3-, as far as I can tell. That is, they are known, and they will not be fixed for the final Firefox 3 release. Some of them will likely be fixed in update releases (e.g. the rare-case crash bugs are likely to have that happen). Some are just issues that are being noted (cross-site XMLHttpRequest) and there are no plans to fix them in Firefox 3.0.x.
This release candidate is really a release candidate: if no new issues that are serious come up, these exact bits will be Firefox 3.
What do you think will get submitted? What actually gets submitted?
Given browser behavior, you're currently safe not escaping the '&' as long as you avoid param names that happen to match any of the 255 character entity references the HTML 4.01 spec defines. Oh, and avoid any other entity references that might get introduces to HTML in the future. Like the several thousand MathML ones, say.
As long as you're willing to take that gamble, no need to escape. But that doesn't make the document valid. You're just relying on very specific error-recovery behavior in browsers.
> Can you get the same result of speeding up webpage loading by > prioritizing which items need to be downloaded?
You can get a perceived speedup, yes. Note that browsers do this: for example, Firefox prioritizes images that are actually displayed over images that are just being preloaded.
Firefox is the biggest consumer of Gecko, and more importantly the biggest test vehicle. The testing that Gecko gets in the Firefox betas is invaluable in identifying and fixing issues.
People have proposed on and off having a separate release cycle for Gecko, but the testing issue means that those ideas haven't really gone anywhere.
Only to the uninformed. The real question shouldn't be "are the right boxes checked?" but "are the standards that I want to use implemented?". ACID3 is only useful in the sense that it gets the latter to happen.
See the posts about Webkits SMIL support (which "fixes" the SMIL part of ACID3), for a good example of the difference.
> Since when did memory usage become such a big deal?
Since people started doing more "wep apps" (and memory usage skyrocketed as a result) and since mobile devices started becoming a real browsing platform. RAM on those is not all that plentiful, so far.
Note that the work to reduce memory usage in Firefox has thus far led to performance improvement, most likely due to better cache coherency. There _have_ been some optimizations to reduce memory usage at the cost of more CPU usage (largely to do with how long decoded 4-bytes-per-pixel representations of images are kept in memory), but most of the memory usage improvements have been due to using a better allocator and fixing leaks. There is no "must have the smallest memory usage around" goal; as you note other considerations are at least as important.
> Thus far, I'm optimistic that Acid3 is improving the overall code quality of > the participating browsers.
I'm not. Some of the issues it brings up are real issues, but some are just diverting resources from fixing things that really matter. The net effect is hard to predict.
Either the thing that's being done with all the other fonts is OK (and the test is wrong, and there should be no need to special case) or the thing being done with all the other fonts is not OK, and this is a crazy hack...
This is not to say that all the changes are like this, by any means. But with the closed-source browsers, who knows?
> Yet somehow it isn't a problem when Israel spends money > given to them by the US on weapons
You mean the money the US explicitly gives them to spend on weapons?
> The way the US behaves here just makes little sense.
That may well be true, yes. Then again, this is generally true of US foreign policy. Part of the problem is never planning more than at most 4 years ahead, if planning at all. Another part is that foreign policy is used as a political tool to get short-term sound-bites at home for the president, etc, which typically undermines actual progress on what foreign policy goals might by accident exist. The whole thing is a huge mess.
Hmm. The money thing is a good point. Going on with that (in spite of Hamas' explicit statements about how they would be spending the money) could have been interesting...
> Since when did the Israeli military become Palestine's police?
Since people started claiming that Israel is an occupying power, with the resulting obligations.
You can't have it both ways. Either you have the responsibilities or you don't. You don't end up with just some of them.
I should note that here we have the elected government firing rockets over the border. Usually, this would be considered an act of war. I'm not sure why people think it's otherwise in this case.
> Israel and West should have given Hamas more rope - > give it a chance to run Palestinian territories
They more or less did, right up to the point where Hamas staged a military coup in Gaza and started firing rockets over the border. Note that Abbas didn't dissolve the government until after said military coup.
A sovereign government firing rockets over a border at the territory of another sovereign government. It's usually called an act of war...
> If the latter, the Hamas government, while fucking with Israel, > would have driven their own people into further misery
> Yet, Firefox won't let me do that even with CSS. > Neither will Opera. That's a cryin' shame in my opinion, > since it wouldn't be *that* much extra work.
Actually, it's a lot more work with CSS. More to the point, it's fundamentally incompatible with the current processing model required by the CSS specification. See http://ln.hixie.ch/?count=1&start=1070385285 for a pretty good description of the problem.
> there is a javascript vulnerability that has gone unpatched for > a while now
Except it's not. The guy who wrote that article is just pretty confused.
Of course figuring that out involves following the relevant bug, because he never publicly admits it when he made a mistake. Then again, he's in the business of making noise, not security, so it's not that much of a surprise.
Because more and more internet stuff is becoming more and more graphics-intensive? People are tossing in huge gobs of CSS effects with shadows, opacity, trying to use SVG filters if they can, etc. Then run the whole thing at 100 frames per second (using setTimeout(0)).
For example, last I checked for Firefox the painting was something on the order of 2-20% of a "typical web site" (mostly text with floats and tables for layout, none of the high-end effects) pageload time. Whether its 2% or 20% depends on the graphics card and driver.
> But it is not pointing out those deficiencies for unfair or useless > browser bashing.
No. It's pointing out some for good reason and some just to get the test count to 100.
> It is pointing the deficiencies out that make it harder for web > developers to develop Web 2.0 applications.
You never addressed my concrete example: How does the interaction of ranges with the text node inside Attr nodes (which is explicitly tested by Acid3) affect Web 2.0 applications? What Web 2.0 applications would even want the performance penalty of having Attr nodes synthesized? Note that Acid3 will give you a pass on that test if you don't implement Attr nodes at all; it'll only fail if you implement them but don't allow range operations on their textnode. It's really pretty closely targeted to fail one particular UA.
> If no web developers wanted a feature, it would not have been > written into a web standard.
This is quite false for the DOM. There were many organizations involved with it that had nothing to do with the web, and large parts of the DOM are aimed at generic XML workflow tools and pretty useless for web developers.
> If no web developers ran into a bug, they would not have known to > test for it.
It's easy to generate some sorts of tests using a random-number generator, actually...
> The bottom line is that the OP is correct.
That the scores don't mean much? Yep.
> but to ensure web browsers support the features requested by web > developers
Nope. Some of the stuff covered by Acid3 falls into this category, but some is just there to pad the total number of tests out to 100. It took a while to find those last few dozen tests to pad out the number after the ones that cover things people really care about had been written...
> As the description for the Acid3 test states,
Yes, Acid3 tests aspects of the DOM. That doesn't mean all aspects of the DOM are useful. A lot of it really isn't.
Slashdot Mirror
What exactly rendered wrong?
Every single one of those known issues is blocking1.9- and firefox3-, as far as I can tell. That is, they are known, and they will not be fixed for the final Firefox 3 release. Some of them will likely be fixed in update releases (e.g. the rare-case crash bugs are likely to have that happen). Some are just issues that are being noted (cross-site XMLHttpRequest) and there are no plans to fix them in Firefox 3.0.x.
This release candidate is really a release candidate: if no new issues that are serious come up, these exact bits will be Firefox 3.
Try putting this as a form action:
http://www.example.com/?gt;<
Then try submitting the form. Take a close look at what actually got submitted.
Note that in HTML you don't need a ';' to terminate entities. For example, consider this action URL:
http://www.example.com/?foo=bar>=something
What do you think will get submitted? What actually gets submitted?
Given browser behavior, you're currently safe not escaping the '&' as long as you avoid param names that happen to match any of the 255 character entity references the HTML 4.01 spec defines. Oh, and avoid any other entity references that might get introduces to HTML in the future. Like the several thousand MathML ones, say.
As long as you're willing to take that gamble, no need to escape. But that doesn't make the document valid. You're just relying on very specific error-recovery behavior in browsers.
> Local variables are local to the whole function
That's being fixed. See http://developer.mozilla.org/en/docs/New_in_JavaScript_1.7#Block_scope_with_let for some documentation. With any luck, ECMA will standardize this as part of EcmaScript 4.
> Can you get the same result of speeding up webpage loading by
> prioritizing which items need to be downloaded?
You can get a perceived speedup, yes. Note that browsers do this: for example, Firefox prioritizes images that are actually displayed over images that are just being preloaded.
Firefox is the biggest consumer of Gecko, and more importantly the biggest test vehicle. The testing that Gecko gets in the Firefox betas is invaluable in identifying and fixing issues.
People have proposed on and off having a separate release cycle for Gecko, but the testing issue means that those ideas haven't really gone anywhere.
> The HTTP 1.1 specification, RFC 2616
Which is currently in the process of being revised. One of the most likely revisions is bumping up the recommended connection limits.
> ACID 3 is symbolic
Only to the uninformed. The real question shouldn't be "are the right boxes checked?" but "are the standards that I want to use implemented?". ACID3 is only useful in the sense that it gets the latter to happen.
See the posts about Webkits SMIL support (which "fixes" the SMIL part of ACID3), for a good example of the difference.
> Since when did memory usage become such a big deal?
Since people started doing more "wep apps" (and memory usage skyrocketed as a result) and since mobile devices started becoming a real browsing platform. RAM on those is not all that plentiful, so far.
Note that the work to reduce memory usage in Firefox has thus far led to performance improvement, most likely due to better cache coherency. There _have_ been some optimizations to reduce memory usage at the cost of more CPU usage (largely to do with how long decoded 4-bytes-per-pixel representations of images are kept in memory), but most of the memory usage improvements have been due to using a better allocator and fixing leaks. There is no "must have the smallest memory usage around" goal; as you note other considerations are at least as important.
> Thus far, I'm optimistic that Acid3 is improving the overall code quality of
> the participating browsers.
I'm not. Some of the issues it brings up are real issues, but some are just diverting resources from fixing things that really matter. The net effect is hard to predict.
> What you are seeing here are not crazy hacks
Well, http://trac.webkit.org/projects/webkit/changeset/31322 would be a change which special-cases one particular font for different handling from all other fonts because that font happens to be the one Acid3 uses.
Either the thing that's being done with all the other fonts is OK (and the test is wrong, and there should be no need to special case) or the thing being done with all the other fonts is not OK, and this is a crazy hack...
This is not to say that all the changes are like this, by any means. But with the closed-source browsers, who knows?
> Yet somehow it isn't a problem when Israel spends money
> given to them by the US on weapons
You mean the money the US explicitly gives them to spend on weapons?
> The way the US behaves here just makes little sense.
That may well be true, yes. Then again, this is generally true of US foreign policy. Part of the problem is never planning more than at most 4 years ahead, if planning at all. Another part is that foreign policy is used as a political tool to get short-term sound-bites at home for the president, etc, which typically undermines actual progress on what foreign policy goals might by accident exist. The whole thing is a huge mess.
Hmm. The money thing is a good point. Going on with that (in spite of Hamas' explicit statements about how they would be spending the money) could have been interesting...
> Since when did the Israeli military become Palestine's police?
Since people started claiming that Israel is an occupying power, with the resulting obligations.
You can't have it both ways. Either you have the responsibilities or you don't. You don't end up with just some of them.
I should note that here we have the elected government firing rockets over the border. Usually, this would be considered an act of war. I'm not sure why people think it's otherwise in this case.
> Israel and West should have given Hamas more rope -
> give it a chance to run Palestinian territories
They more or less did, right up to the point where Hamas staged a military coup in Gaza and started firing rockets over the border. Note that Abbas didn't dissolve the government until after said military coup.
A sovereign government firing rockets over a border at the territory of another sovereign government. It's usually called an act of war...
> If the latter, the Hamas government, while fucking with Israel,
> would have driven their own people into further misery
That's exactly what's going on right now, yes.
> Yet, Firefox won't let me do that even with CSS.
> Neither will Opera. That's a cryin' shame in my opinion,
> since it wouldn't be *that* much extra work.
Actually, it's a lot more work with CSS. More to the point, it's fundamentally incompatible with the current processing model required by the CSS specification. See http://ln.hixie.ch/?count=1&start=1070385285 for a pretty good description of the problem.
> there is a javascript vulnerability that has gone unpatched for
> a while now
Except it's not. The guy who wrote that article is just pretty confused.
Of course figuring that out involves following the relevant bug, because he never publicly admits it when he made a mistake. Then again, he's in the business of making noise, not security, so it's not that much of a surprise.
Pages that big are pretty common. All sorts of mailing list archives, any long text document, etc.
We routinely get bug reports with people complaining that their multi-megabyte (often tens of megabytes) HTML file doesn't render instantaneously...
The HTML is cached too. It's just not guaranteed to not be evicted from the cache. Neither is anything else.
Because more and more internet stuff is becoming more and more graphics-intensive? People are tossing in huge gobs of CSS effects with shadows, opacity, trying to use SVG filters if they can, etc. Then run the whole thing at 100 frames per second (using setTimeout(0)).
For example, last I checked for Firefox the painting was something on the order of 2-20% of a "typical web site" (mostly text with floats and tables for layout, none of the high-end effects) pageload time. Whether its 2% or 20% depends on the graphics card and driver.
> That's not what Acid3 is testing, however.
;)
Are you sure?
> But it is not pointing out those deficiencies for unfair or useless
> browser bashing.
No. It's pointing out some for good reason and some just to get the test count to 100.
> It is pointing the deficiencies out that make it harder for web
> developers to develop Web 2.0 applications.
You never addressed my concrete example: How does the interaction of ranges with the text node inside Attr nodes (which is explicitly tested by Acid3) affect Web 2.0 applications? What Web 2.0 applications would even want the performance penalty of having Attr nodes synthesized? Note that Acid3 will give you a pass on that test if you don't implement Attr nodes at all; it'll only fail if you implement them but don't allow range operations on their textnode. It's really pretty closely targeted to fail one particular UA.
> If no web developers wanted a feature, it would not have been
> written into a web standard.
This is quite false for the DOM. There were many organizations involved with it that had nothing to do with the web, and large parts of the DOM are aimed at generic XML workflow tools and pretty useless for web developers.
> If no web developers ran into a bug, they would not have known to
> test for it.
It's easy to generate some sorts of tests using a random-number generator, actually...
> The bottom line is that the OP is correct.
That the scores don't mean much? Yep.
> but to ensure web browsers support the features requested by web
> developers
Nope. Some of the stuff covered by Acid3 falls into this category, but some is just there to pad the total number of tests out to 100. It took a while to find those last few dozen tests to pad out the number after the ones that cover things people really care about had been written...
> As the description for the Acid3 test states,
Yes, Acid3 tests aspects of the DOM. That doesn't mean all aspects of the DOM are useful. A lot of it really isn't.
None of the things this test tests are "International Standards" in the ISO sense.
> so I used one from a few days before the Acid3 test was published
You do realize preliminary versions of this test have been available for a while now, right? For example, https://bugzilla.mozilla.org/show_bug.cgi?id=410460 was filed over two months ago.
If you want to see what things looked like before people started on fixing this stuff, you'll need to go back a few months.
Really? All the issues Acid3 tests plague web developers? Ranges inside Attr nodes, for crying out loud?