After looking at how Safari 3.1 handles the Acid2 test, and finding that under some circumstances/platforms it fails the test, I realized: that one line, with the eyes, has been the cause of most regressions in browsers that previously passed the test.

Rows 4-5 test fallback behavior for objects. The idea is that if a page tries to load an external resource, but can’t—the file is missing, the server’s down, the network’s slow, the browser doesn’t have the right plugin, etc.—the page can provide alternate content. And it can be nested, so you can try, say, a video clip that falls back to an SVG image that falls back to a PNG that falls back to text. The Acid2 guide goes into more detail, with the relevant section of code being this:

<object data="data:application/x-unknown,ERROR">
  <object data="http://www.webstandards.org/404/" type="text/html">
    <object type="image/png" data="data:image/png;...">ERROR</object>
  </object>
</object>

So it tries to load the first object, which is deliberately made unloadable. Then it tries to load the second object, which calls out to a webpage which is supposed to be unavailable. Then it falls back to the third object, which is an embedded image of the eyes.

The problems have been with the second object, the one hosted outside of the test file itself.

Back in December, when Microsoft announced that their internal builds of IE8 passed Acid2, lots of people started checking it in the Firefox 3 beta, Safari, and Opera, browsers that were known to pass. And they were surprised to find it didn’t work. It turned out that the server config on www.webstandards.org had changed such that the file requested actually returned a page instead of an error, so browsers were properly loading that page instead of the eyes. It was suggested that people use an alternate copy of the test that pointed to a different external resource.

Then when IE8 beta1 came out, people rushed to try it themselves. By this time the server config had been fixed, so the official copy of the test worked again. But people trying it on alternate copies ran into a problem, because it tripped a cross-site security check (IE8b1 would only load objects from the same domain) and IE8 wasn’t using the fallback content if it was blocked for security reasons. (This makes absolutely no sense. It’s like refusing to let someone board a plane if they trip a metal detector, instead of checking to make sure they didn’t miss a few coins and having them walk through again. Add to that the fact that IE is perfectly happy to load images, iframes, Flash animations, etc. from other sites, and the restriction itself seems a bit silly.)

So now Safari 3.1 is out, and has problems with exactly the same line. In my test on Windows, it displays this dithered orange band. In my test on Mac OS, it looks like this for a few seconds, but continues to display the page-loading icon. Then it finishes loading and displays the eyes, passing the test. It looks like it’s just taking a couple of seconds to check that external resource before falling back to the alternative.

I just find it interesting that all of these come down to one single piece of the test, and it’s the piece that tries to load an external resource—something that isn’t within its own control.