Slashdot Mirror
Does IE8 Really Pass Acid2? [Updated]
thevirtualcat found some inconsistencies in IE8's Acid2 results that made him wonder what's going on. Can anyone replicate these results or, better yet, explain them?
Update: 03/22 23:54 GMT by KD : Several readers pointed out this has to do with cross-site scripting prevention, as described here.
Update: 03/22 23:54 GMT by KD : Several readers pointed out this has to do with cross-site scripting prevention, as described here.
As TFA mentions (at the very end!) this is explained here.
Summary: cross-site security means that if you move the test off the original domain, the test changes. In fact IE8 does the wrong (nonstandard) thing in these cases, but according to them it's more secure (it fails earlier). They're considering making it more standards compliant once they're convinced it's secure enough.
The reason you're seeing the result is due to an "overly secure" default for beta 1 when it comes to cross-domain embedded objects.
:)
Here's the explanation:
http://blogs.msdn.com/ie/archive/2008/03/05/why-isn-t-ie8-passing-acid2.aspx
Google is your friend next time...
The Acid tests are test cases used to assess a browser's web standards support.
Yet, in the explanation of the incorrect rendering at the IE blog, AciveX is invoked, with some excuse about cross-domain security.
ActiveX has absolutely nothing to do with Web Standards.
This leads me to believe that MS plans to keep playing the Internet game by their rules for a while yet.
"Be light, stinging, insolent and melancholy"
Microsoft is right to turn cross-domain restrictions on by default. Cross-domain is the same as cross-site, and we all know the pain XSS vulnerabilities can bring. The failure of "copies" of acid2 to render correctly in IE8 are actually due to the "copies" of acid2 being "copied" incorrectly. To copy the acid2 test, you have to make slight modifications to the test contents itself to update the test for the domain it is being hosted on. Them are the breaks of complex tests. Acid2 is a complex test and cannot simply be copied carte blanche.
IE8 has a problem initiating fallback content when a resource can not be acquired. This is exactly what this particular part of the acid2 test is meant to test, fallback code. The fact is, that IE8's fallback behavior works correctly in some cases, but not in others. Specifically, the fallback code works if the failed to acquire resource is supposed to be on the same domain as the acid2 test, whereas if they are on different domains, IE8's code fails to behave properly.
The fact that the blog writer mentions security is a red herring. While it is true that this does have something to do with security code, the real problem is that the fallback behavior is poor.
Write your own Choose Your Own Adventure. http://www.freegameengines.org/gamebook-engine/
The IE team announced their internal IE8 build passed Acid2 in mid-December. Acid3 was released March 3. IE8's first public beta went out on March 5.
Acid3 had been in development for 11 months so it's not like this suddenly sprung into existence overnight to "prove" Microsoft's inadequacies or anything. Even if you consider the release date to be intriguing, I'm not sure what difference you think the Acid3 developers thought it would make to have IE8 fail Acid3. It's not like there are really any users who decide which browser to use based on its ability to accurately render complete standards anyway. Most people don't know what the web standards Acid tests are and won't care even if you tell them.
Putting all that aside, it would still hardly constitute some unfair conspiracy. For one thing every other renderer in released browsers fails quite miserably at it too. Secondly, it's not some arbitrary test, Acid3 measures accuracy of conformance to DOM and ECMAscript standards. Acid3 didn't just make up the standards on the spot, they have existed for years and IE could have (and should have) been attempting to conform the whole time (as should every other renderer).
In other words: No, I don't find it intriguing. It's a mild coincidence, nothing more.
Spelling mistakes, grammatical errors, and stupid comments are intentional.
No, it does not pass.
There is no cross-domain insecurity in <object> as defined by the HTML specification. There is a problem in IE8's broken implementation.
If object can't be displayed, browser should ignore it. Ignored <object> isn't any more dangerous than <div>. In such case there's only one document, with one DOM, all within same domain.
But apparently IE8 can't ignore undisplayable <object> properly, so they've hacked around the problem by spawning new IE8 instance that pretends to be a plug-in that handles the invalid <object> (an <iframe> effectively). And when you do stupid things like that, of course you've got a security problem!
No Acid2-passing browser has any problems with displaying same-origin fallback to cross-domain object.
"Be light, stinging, insolent and melancholy"
Acid3 isn't a standard, it's a set of tests for specifications that have already existed for years. Acid3 didn't make Firefox less compliant, it merely pointed out ways in which Firefox was already non-compliant.
Bogtha Bogtha Bogtha
Auto margins failing to centre block elements is a hallmark of quirks mode, which means that you aren't using a doctype, which means that you are writing invalid code, which means that you aren't in any position to criticise others for not following the specifications.
Bogtha Bogtha Bogtha
If you go to the appropriate wikipedia page you will see a long list of CSS 2 and 3 features.
Beside this list is all the major browsers and how they implement each feature (fully, partially, broken, not implemented, etc...).
Voila! Partial compliance.
...even if it's a shame it's taken this long to get there. Pre-releases of Safari and Konqueror passed this almost exactly 3 years ago, and Opera's Presto engine wasn't far behind. The fact that Gecko has taken nearly as long to catch up as IE/Trident is disturbing, but they had their own self-inflicted issues to fix (XPCOM? ewww).
All of this can only mean web developers sleep more soundly at night, and more real work gets done. The IE developers can give themselves a big pat on the back for achieving something useful that will make everyone's lives better, like they used to do with IE3 and 4 and initial CSS1 support. Shame the management decided to slack off on IE development so long. Microsoft: intelligent geeks, ruined by management.
Now, on to Acid 3. IE8 is still clearly trailing everyone else by some distance and is probably going to play catchup for a while yet until they implement native SVG (think about the possibilities for Explorer and Office, that Apple, KDE and friends are just beginning to explore).
As an aside, think how good MS Office might be if they had this level of competition due to having to implement a proper Open Document standard not specified by them. Everyone would get more work done, would be fitter, happier, healthier and better, and Microsoft would probably still have the lion's share of the market. OOXML needs to die now, for everyone's sake, including Microsoft's.
To maintain compatibility and be secure by default we didn't want to invoke fallback either, as original web authors might not have intended this behavior. As we all know, developers (developers, developers, developers) NEVER intend for a fallback resource to be utilized when primary resources fail. Microsoft has once again taken the initiative to embrace the developer community as a loving parent and save us from our own incompetent, foolish selves.
"What does 'It's not a bug, it's a feature' mean, daddy?"
"I'll tell you when you're older."
CAn'T CompreHend SARcaSm?
One must ask, does IE 8 only fail on cross site objects of type text/html, or are other cross site objects affected? (e.g. flash, embedded youtube videos, quicktime, etc)...
Come as you are, do what you must, be who you will.
Validity is a property of documents; a doctype declaration alone cannot be valid or invalid. But that code is incorrect, you've forgotten the public identifier. That code also puts other browsers into quirks mode.
There's more than one ISO HTML 2000 doctype declaration available. As for correctness, that depends on whether or not you screw the syntax up. But next to nobody uses that doctype anyway. Can you name a single HTML tutorial that mentions it? The OP wondered if he was reading the wrong tutorials, in my experience, it's common for tutorials to miss out doctypes altogether and unheard of for them to mention ISO-HTML at all. So we can reasonably eliminate that from consideration as well.
It is not invalid, but you shouldn't do so when serving it as text/html as it goes against the compatibility guidelines in the XHTML 1.0 specification, which RFC 2854 requires you to follow. Further, Internet Explorer hasn't chosen quirks mode for documents with XML prologues since version 6, so that's not the issue here either.
There's nothing wrong with that, although again, it's not something tutorials teach. You can divide HTML tutorials into two different groups: one doesn't mention doctypes and the other says that the doctype must come first (or straight after the XML prologue).
But "some IE versions" isn't relevant here, we are talking about version 8 in particular. Are you actually looking for an explanation for the problem, or are you just trying to find a way of blaming Microsoft? Doctype switching has been around for many years, all major browsers do it, and it's silly to blame Microsoft for auto margin centring not working when Internet Explorer has supported it for seven years.
Bogtha Bogtha Bogtha
Let's do exactly what you suggest, and "RTFM". From the Acid3 page at webstandards.org, with links to the specifications and dates added by me:
As you can see, the majority of the Acid3 test is comprised of behaviour described in specifications published years ago, with a substantial portion of them over five years old and some over a decade old.
Actually, CSS 3 is not a single specification, but a group of
Bogtha Bogtha Bogtha