Does IE8 Really Pass Acid2? [Updated]

← Back to Stories (view on slashdot.org)

Does IE8 Really Pass Acid2? [Updated]

Posted by kdawson on Sunday March 23, 2008 @10:31AM from the two-green-eyes-please dept.

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.

17 of 174 comments (clear)

Min score:

Reason:

Sort:

The answer... by 26199 · 2008-03-23 10:32 · Score: 5, Informative

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.
1. Re:The answer... by kat_skan · 2008-03-23 11:38 · Score: 4, Informative
  
  Actually, Microsoft is not correct. The browser is supposed to be unable to load the object that is tripping IE's cross-domain security features. Regardless of whether the object fails to load because of security policies or because the resource flat out doesn't exist, the test is constructed so that the browser will display the fallback content for the object, which IE does not do.
2. Re:The answer... by cheater512 · 2008-03-23 12:45 · Score: 4, Informative
  
  Microsoft did the correct thing with the cross domain scripting stuff.
  
  However they then ignore the fall back content hence the problem.
  The standard says that if there is a problem with the object tag then the html inside the html tag should be shown.
  IE8 has a problem with the object tag and then ignores the fallback completely.
  
  Why does it work on the official site?
  Because its not cross scripting anymore, instead it fetches the page and gets a 404.
  It then uses the fallback content.
  
  In summary: Microsoft is making their own standard as per usual.
3. Re:The answer... by pohl · 2008-03-23 12:59 · Score: 5, Informative
  
  So the behaviour mandated by the standard is insecure?
  No, that is not the case. IE8 is trying to prevent exploitation of their own, proprietary ActiveX API, and simply needs to make some minor corrections to make sure that they do it in such a way that does not violate the standards. The standards don't need to be revised since nobody else implements the swiss cheese that is ActiveX.
  
  --
  The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
4. Re:The answer... by VGPowerlord · 2008-03-23 17:07 · Score: 2, Informative
  
  But why is it OK to process the fallback (a data url) if the failed page is on the same domain, but not if it's on a different domain?
  
  The spec says you must try to render the fallback if an object is not processed because the browser is configured not to render it. I quoted the relevant section in my last post.
  
  --
  GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
Comment removed by account_deleted · 2008-03-23 10:34 · Score: 2, Informative

Comment removed based on user account deletion
Re:On another note... Acid3 by Your.Master · 2008-03-23 11:12 · Score: 4, Informative

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.
Re:I smell bullshit at the IE blog by Chris+Snook · 2008-03-23 11:18 · Score: 5, Informative

IE8 is using ActiveX *internally* because it can't natively render the html OBJECT. Invoking ActiveX triggers XSS checks. The bottom line is that they technically pass the test, but many web designers will do things that really should work, but won't in IE8. It's not because MS is cheating, just that they haven't fully implemented this feature, and they're erring on the side of caution with their partial implementation. Regardless of standards compliance, they'll need to fix this before IE8 is released.

--
There's no failure quite as dissatisfying as a complete and total solution to the wrong problem.
Re:Yes, that's true. by bistromath007 · 2008-03-23 11:36 · Score: 1, Informative

I 3 Firefox and all, but it's not standards compliant. Tried Acid 3?
Re:Simple stuff like CSS by Anonymous Coward · 2008-03-23 12:02 · Score: 2, Informative

Have you specified a valid doctype? Even IE8 will probably degrade into quirks mode without one, which will cause auto margins to fail.
Re:just use firefox by liquiddark · 2008-03-23 12:06 · Score: 2, Informative

Of course, 2.0.0.1.2 Firefox doesn't pass Acid2 either. So, not so much.
Re:Simple stuff like CSS by Bogtha · 2008-03-23 12:34 · Score: 4, Informative

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
Re:It's a massive improvement... by 99BottlesOfBeerInMyF · 2008-03-23 12:57 · Score: 2, Informative

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...
The Webkit nightly is up to 95/100 on Acid 3. Anyone run Gecko nightly lately?
Re:This is not a security problem, per se. by Anonymous Coward · 2008-03-23 14:30 · Score: 2, Informative

You should read. The explanation that he gave, I will now give, in my own words, hoping that you will read them correctly this time.

The portion of the acid2 test that is at issue with IE8 here works like this:

1. The test has markup that points to an object at http://www.webstandards.org/404/; basically, the object's not there, on purpose.
2. The test has subsequent markup that contains a data: URI with embedded replacement/fallback content.

What should happen?

Two claims:

1. MS IE team: Because the lark document resides on a different domain if you run the test from another site, they feel it's insecure to check some other domain's content like that.
2. Rest of us: We acknowledge that it is in fact nice of them to be security minded in this way, BUT the fallback content is still there, embedded in the test, and they should go ahead and render it if they aren't able to get the first-ordered content because of a 404 OR because they are paranoid.

It's content designed to be used in the place of the real content if for whatever reason (offline browsing? paranoia? maybe the original content was eaten by a grue?)
Re:Yes, that's true. by NickCatal · 2008-03-23 14:42 · Score: 2, Informative

Actually, the nightly build of WebKit (OS X) is already at 95/100. The latest Safari isn't nearly as high.

Not like it matters. By the time anyone trys something that is in the ACID3 test there will be an ACID4 that nobody can get to 100 with

--
-nick
Reverse yellow boxes.... by AstroPHX · 2008-03-23 16:07 · Score: 2, Informative

All ACID tests are attempts at benchmarking the ability of a browser to apply standards (W3C standards, to be specific) correctly. Unless your browser showed you the image exactly as it appears here http://acid3.acidtests.org/reference.html, your browser did not pass the ACID3 test.

I do not see any "'t's in reversed yellow boxes" in the reference document, so I am going to go out on a limb and suggest your browser does not pass the ACID3 test.
Re:Yes, that's true. by Bogtha · 2008-03-24 06:23 · Score: 4, Informative
The Acid3 test is a NEW test that uses/tests the NEW feature that the CSS3 intoduces.
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:
Here is the list of specifications tested:
- DOM2 Core [specification published in 2000.]
- DOM2 Events [specification published in 2000.]
- DOM2 HTML [specification published in 2003.]
- DOM2 Range [specification published in 2000.]
- DOM2 Style (getComputedStyle, ...) [specification published in 2000.]
- DOM2 Traversal (NodeIterator, TreeWalker) [specification published in 2000.]
- DOM2 Views (defaultView) [specification published in 2000.]
- ECMAScript [specification published in 1997, although I could only locate the third edition, published in 1999.]
- HTML4 (<object>, <iframe>, ...) [specification published in 1997.]
- HTTP (Content-Type, 404, ...) [specification published in 1999.]
- Media Queries [specification published in 2002.]
- Selectors (:lang, :nth-child(), combinators, dynamic changes, ...) [specification published in 2001 , with some of it part of the CSS 2.0 specification published in 1998 .]
- XHTML 1.0 [specification published in 2000.]
- CSS2 (@font-face) [specification published in 1998.]
- CSS2.1 ('inline-block', 'pre-wrap', parsing...) [specification published in 2007.]
- CSS3 Color (rgba(), hsla(), ...) [specification published in 2003.]
- CSS3 UI ('cursor') [specification published in 2004.]
- data: URIs [specification published in 1998.]
- SVG (SVG Animation, SVG Fonts, ...) [specification published in 2001.]
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.

CSS3 intoduces many changes,
Actually, CSS 3 is not a single specification, but a group of
--
Bogtha Bogtha Bogtha