IE8 Beta 1 experiences Acid2 hiccups, while Acid3 is rolled out
Testers anxious to see the first Internet Explorer edition that passes a Web standards test by default, were disappointed yesterday to discover it wasn't passing as expected. Naturally, Microsoft had an excuse on hand.
A choice regarding the default handling of ActiveX controls, according to Internet Explorer developer Phil Nachreiner late yesterday, forced the first public Beta 1 build of IE8 to fail the independent Acid2 test for public standards.
"IE8 fails the copies of ACID2 due to the cross domain security checks IE performs for ActiveX controls," Nachreiner wrote. "Since IE does not natively handle HTML content in the OBJECT tag, but rather uses IE's rendering engine as an ActiveX to display this HTML content, the same cross domain security checks also apply."
BetaNews has been working to independently verify Nachreiner's report, though thus far, we've actually been unable to properly install IE8 in our virtual Vista environment. As of 11:30 am, the installation routine fails to properly identify updates that have already been installed. As a result, once IE8 "thinks" it's installed, most of the screen rendering features of Vista no longer appear to be assessing the correct screen resolution -- so for instance, sidebar gadgets are rendered with some parts at the proper size and some not. (Internet Explorer's renderer is also responsible for the appearance of gadgets.)
12:30 pm EST March 6, 2008 - Once we got a semi-working copy of IE8 running on our Windows Vista virtual machine (note: we haven't installed Service Pack 1 yet), we actually got better results with Acid2 than many others.
For our virtual machine, which was posing some rendering problems, we did have to scale the rendering to 82% -- which may be why slight lines appear under the smiley-face's nose and mouth, like unwanted facial hair. But although we saw the same window gadget controls as revealed in Nachreiner's post in place of the radio-button eyes for about two seconds, they were soon replaced with well-rendered eyes.
That fact suggests that IE8 -- which for our tests was running in its new, native IE8 standards mode -- actually did parse the fallback URL address, rather than discard it as Nachreiner stated it did.
While we had a moment, we did go ahead and try the Acid2 test in IE7 emulation mode, which is available from a prominent button on the new IE8 toolbar. Of course, it failed spectacularly.
We also tried IE8 in its native mode on the new Acid3 test, and there too, we scored better than others were reporting...though not much better: 17 out of 100. When rendered properly, Acid3 should show an array of differently colored boxes, from small to large. IE8 Beta 1 instead showed the same boxes, but way, way down the page, most in black except for the final one in grey.
2:50 pm EST March 6, 2008 - A lot has to do, we learned, with the domain the Acid2 test hails from: The version which passed is hosted on www.webstandards.org. The version which fails IE8 due apparently to the cross-checking domains problem to which Nachreiner refers, is hosted on webstandards.org (without the subdomain).
It's exactly the same test, though the relative placement of the domain from which the test and the fallback are hosted, are apparently the cause of the mis-rendered eyes, when and if they are mis-rendered.
One other possible culprit may involve a new IE8 feature called deep zoom, which is capable of scaling graphics and text to larger or smaller sizes to fit a given resolution. When we managed to get IE8 to run -- albeit, not well -- we noticed that its default zoom resolution was not well calibrated with where "100%" should be. A normal-sized rendering was more like 82% on IE8's new variable zoom scale.
Right now, it looks like someone threw down our system clock onto the desktop and smashed it into a dozen pieces. Once we work that beta bug out, we hope to see the Acid2 test for ourselves.
Nachreiner's explanation went into further detail: Currently, he said, the Acid2 test gives a URL for a "fallback rendering" of an embedded object. Apparently as a benefit of Microsoft's settlement with Eolas, IE can now handle ActiveX rendering however it chooses; and this time, Microsoft has chosen to offload the task of rendering ActiveX controls to a separately instantiated version of the renderer. For security reasons, cross-checking takes place between the browser container and the component.
But that would mean the URL of the fallback rendering would have to be checked for validity...and because that can't happen now, the "eyes" in the smiley-face for the Acid2 test, produced by two radio button controls, can't be rendered normally.
"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," wrote Nachreiner. "We started with the most secure solution and are now looking into whether we can safely loosen this restriction in a future beta."
The fallback mechanism dates back to a W3C proposal for HTML 4.01, dated December 1999.
While all this was going on, the Web Standards Project -- with which Microsoft said it has been consulting -- moved the goalposts for standardization once again with its rollout of the Acid3 test, ostensibly to replace Acid2.
"Acid3 goes beyond the CSS tests implemented by Acid2 and tests a browser's DOM Scripting capability, as well as continuing to probe visual rendering of CSS, SVG and webfonts," reads the official explanation posted to the Project's Web site on Monday.
Initial Acid3 test scores using apparently working copies of IE8 Beta 1 were hauntingly low, including this one from an independent tester posting to the IE8 development site. His score was a 12 out of 100; a later contributor reported a 14.