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.

Comments

Re:The answer...

[26199]

In a word, no.

Next anti-Microsoft flame, please?

This is not a security problem, per se.

[WK2]

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.

Re:On another note... Acid3

[ben there...]

Notice they have a "Task Force" for testing Microsoft, but no such group for Firefox, Opera, Safari, etc. Not that surprising, really. There are entire websites devoted to helping web designers hack around IE bugs. If only a single browser could pass Acid2 and Acid3, ideally that browser would be IE. It's used by the most people, so you must design around its flaws. Not to mention, if that were to happen, Firefox and Opera would do everything possible to catch up immediately. Then we wouldn't have to hack around any browser's flaws.

Re:Yes, that's true.

[Bogtha]

Acid3 was recently released so that people have new standards to meet.

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.

Re:The answer...

[VGPowerlord]

I disagree. It should fall back to the data url when loading the other object failed. Not only that, but the HTML standard agrees with me on this:

If the user agent is not able to render the object for whatever reason (configured not to, lack of resources, wrong architecture, etc.), it must try to render its contents.

and

One significant consequence of the OBJECT element's design is that it offers a mechanism for specifying alternate object renderings; each embedded OBJECT declaration may specify alternate content types. If a user agent cannot render the outermost OBJECT, it tries to render the contents, which may be another OBJECT element, etc.

Re:It's a massive improvement...

[marm]

Because the file format limitations are what (at least as far as I can see) are what keep the competitors from being viable alternatives.

I'm an IT manager by trade. I don't care who provides my company with software or what platform it runs on, as long as the business I provide IT for benefits from it and it is cost-effective, ideally giving me an advantage over my company's own competitors. The changes in UI between MS Office XP (which they're mostly using now), 2003 and especially 2007 are big enough that I have to retrain my users to use them, and frankly the cost of training my users to use 2007 is enough that I've been seriously considering moving them to OpenOffice.org.

However, the lack of a properly standardized file format prevents me from doing that. I have experimented with OOo with some of my users, and the biggest complaint (once I have trained them up a bit in OOo) I have is that .doc documents they are sent frequently don't look or print right, or they don't look right on the receiving end. If they can cope with that, I have found OOo gives me fewer support calls, primarily because the text rendering engine in OO Writer is more predictable than that in MS Word. Every few days I have to send someone to look at a user's Word document because the formatting does not work as they expect, particularly if the document contains columns or per-paragraph margins. In OO writer, those same documents behave exactly as expected. I can't understand how MS Word has got it wrong for so long - the bugs I see in Office XP are exactly the same in 2007. OO.org does it right, MS Word doesn't, and the only reason I can't reduce those support calls is that my users expect to be able to import and export external documents perfectly each time. There are similar issues with OO Calc vs. Excel also, particularly with regards to external data sources that Excel seems to forget about with no rhyme or reason, but which OO Calc gets right all the time, every time.

I know from experience with KOffice that I get better import - pretty much spot-on for the fairly complex documents my users create - from that into OO.org as ODF than I do Word documents into OO.org, so there must be something good about having a properly standardized file format. My conclusion therefore is that if MS Office had to support ODF, then MS would be forced to fix the bugs in Word and Excel rather than rely on their proprietary file format to keep competitors out and ignore the problems.

This is a similar situation with IE8 finally fixing long-standing bugs in order to pass the Acid 2 test, which is only possible by HTML and CSS being properly standardized.