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.

It looks like there’s a server error on www.webstandards.org, and I’m trying to report it—but emailing them is just kicking back “user unknown” errors, and the spam protection on their blog refuses to let me comment, claiming that my user-agent has changed since I read the post. Um, no, I may have looked at it with more than one browser, but the one that loaded it is the one that’s submitting it.

So, Web Standards People, you want to fix your test?

Fix your 404 page.

Rows 4-5 test nested <object> support. The intent of the spec is that if a remote object cannot be retrieved, the browser will instead display the content inside it, on the HTML page itself.

One of the objects is trying to load content from http://www.webstandards.org/404/. Normally this fails, and the browser displays the fallback content — the eyes on the happy face. Right now that page is returning an HTTP status code of “200 OK” instead of “404 Not Found” — so the browsers, including Opera 9, Safari 3, Konqueror 3 and Firefox 3 beta, are all dutifully showing the content of that page in a tiny rectangle with scrollbars.

Update: Thanks to several Slashdot posters for pointing out that the test author, Ian Hickson, has a second copy of the test that points to a different URL for the <object> fallback test, and currently works as expected.

An internal build of Internet Explorer 8 has passed Acid2.

The Acid2 test was released in April 2005 to test a number of pieces of the HTML and CSS standards that, at the time, no modern browser handled according to spec. The purpose of the test was to prod browser developers into improving their products, and to do so consistently, so that developers would have more tools available for cross-browser sites.

At the time, Microsoft dismissed its its importance entirely. Even though they were working on rendering improvements for IE7, they stated that Acid2 was not one of their goals. Meanwhile Opera and Firefox were both in the wrong phase of their development cycles to make sweeping changes, so Safari jumped on it and became the first browser to pass. (Every once in a while I see someone say Opera was the first, and I have to wonder where they were.) Opera followed with version 9, and the Firefox 3 betas pass it as well.

With Gecko (Firefox), WebKit (Safari), Opera and IE accounting for the four biggest web browsers and the most popular minor browsers (Flock, Camino, Shiira, etc., plus IE shells like Maxthon), this shows unprecedented convergence among clients. It will be much easier to develop a cross-browser website that runs on IE8, Firefox 3, Opera 9+ and Safari 3+.

There are, of course, many aspects of the specs that aren’t covered by Acid2. And there are emerging standards like HTML5 and CSS3. And there are plenty of other bugs, quirks, and extensions among various browsers (IE’s bizarre concept of having layout, for instance, trips up all kinds of weird issues). And then there’s waiting for IE8 to be released, and moving people up from IE7, not to mention all the people we still have to move up from IE6. Full benefit is probably at least 3 or 4 years away. *sigh*

(via WaSP Buzz)

Opera cautioned that upcoming development builds could regress, but we can expect the final version of Opera 9 to pass the test.

Neither Internet Explorer 7 nor Firefox 2 will make any attempt to pass Acid2, but Mozilla is working on Acid2 fixes in the next version of their rendering engine, Gecko 1.9, which will likely appear in Firefox 3.

So who’s next? Well, Opera 9 beta 1 is very close—there’s a pair of red squares that should be black, but that’s it. Neither IE7 nor Firefox 1.5 will have much in the way of Acid2-related fixes, though the trunk builds of Firefox show improvement, so 2.0 has a chance 3.0 might make it will pass (since 2.0 will use the same engine as 1.5).

Speaking of Opera, they’re close to passing Acid2 in-house. They seem likely to be the next browser to pass (after Safari, iCab, and Konqueror). The next question is: Who will be the first to release a final version that passes the test? Safari and Konqueror still only pass on the development branches, and iCab’s still in beta.

I did a double-take. iCab? Das Internet-Taxi für den Mac? The browser with the nice “Make iCab smile” campaign to encourage non-broken HTML on websites but CSS capabilities that have rivaled Netscape 4 as little better than a bad joke? That has been in perpetual beta for years with no sign of shipping a final release?

So I did the only thing I could do. I downloaded the new beta and tried it. Not only did it nearly pass Acid2 (there was a narrow white line across the middle of the face) but it actually handled all the layouts on my own site… something which it had always failed at spectacularly before.

The WaSP Buzz posted a congratulatory note to both this morning. Strangely, iCab is the first browser available to the general public that passes Acid2. The up-to-date Safari is still sitting inside Apple’s development labs, and while you can download the source for the updated Konqueror, you’ll have to wait for KDE 3.4.2—or possibly 3.5—to be able to use it yourself without running a bleeding-edge desktop. Update: Apple has just launched CVS access to WebCore, putting Safari in the same situation as Konqueror: you can download and compile the latest source code if you want, but if you just want to grab an installer, you’re gonna have to wait.

No word on when the fixed version will make it into users’ hands (probably with the first update to Tiger), but he’s posted all the patches for KHTML, so the Konqueror team can start working the fixes back into the main codebase.

Congratulations, Dave!

The Acid2 test is a single page of HTML and CSS designed to use parts of the spec that today’s browsers handle incorrectly or not at all. According to the rules, the code should display a happy face… but at the moment it produced varying levels of gibberish. So far Firefox seems to handle it the least badly (I hesitate to say “best”), with Opera and Konqueror at about the same level (you can at least see a circular outline), and Internet Explorer looking like a piece of modern art.

Well, we know Safari is working on it (and the fixes should feed back into Konqueror). One of the test’s architects is high up at Opera, so you can bet they will be improving. I imagine people are already submitting bug reports to Mozilla. [Update: found the tracking bug in Bugzilla.] That leaves Internet Explorer. They’ve been notoriously reluctant to update their rendering engine, but they did ask for specific requests. I don’t have much confidence in seeing fixes in IE 7, but you never know…

Anyone want to place bets on who progresses the fastest?