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.)
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.