IE8 May Not Pass the Acid2 Test After All

dotne writes "CNET has published an article called Acid2, Acid3 and the power of default. The article predicts that IE8 will not pass the Acid2 test after all: '[Another] scenario could be that Microsoft requires Web pages to change the default settings by flagging that they really, really want to be rendered correctly. Web pages already have a way to say this (called doctype switching, which is supported by all browsers), but Microsoft has all but announced that IE8 will support yet another scheme. If the company decides to implement the new scheme, the Acid2 test — and all the other pages that use doctype switching — will not be rendered correctly.' Microsoft's IE8 render modes have been discussed here previously, and they've caused an uproar in the web development community. According to the scheme, authors must put Microsoft-specific <meta> tags into their pages in order for them to be rendered correctly. I doubt Acid2, nor Acid3 will have Microsoft extensions in them."

Comments

Page specific tuning

[mini me]

It's possible that IE8 will contain code that detects the presence of an ACID test and switches to the proper renderer to pass the test.

Re:Page specific tuning

[ozamosi]

The author of Acid2/3 is not amused by this meta tag. From the tone of that blog post, to me it sounds like he wouldn't shy away from actively try to break a mechanism like that by changing the URI to make sure that the browser that passes the Acid test actually does so for real.

Note, though, that he doesn't say that explicitly, and you shouldn't assume that he will. It's my own conclusion, and you should draw your own, etc...

Re:Page specific tuning

[TENTH SHOW JAM]

Opera, Mozilla/Firefox don't have this problem so why should Microsoft.

My current version of Firefox does not pass Acid2. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11

Any browser that follows the standard deserves my admiration. Adding more meta tags where this stuff should be in the doc type is not a correct decision and should be reviled.

Make Acid2 the Default

[Ohio Calvinist]

Why not make Acid2 the default? I'm sure the browsers interals could look for IE6/7 "hacks" and provide a icon on the bottom to have it viewed in compatibility mode? If the broken mode is going to be the default, I think standardization will be slow, unless common developer tools like MS Visual Studio and Dreamweaver put in the MS Specfic renderer tags in by default.

I think we're at the moment when developers want standards, where in the IE4/NS4 war, everyone and their brother was trying to hack-together web pages, and IE did some nice exposition of the DOM via the ID attribute in tags, which accomodated less-skilled programmers. Now that the baseline-developer's skills are improved, and the IDEs out there are actually pretty decent (e.g. Not FrontPage, Not MS Word) I'd say the time is right.

While the Acid2 test is niceity, what I'd really love to see is a standard plugin model shared by FF and IE. It has been a while, but I always thought the "EMBED" inside of an "OBJECT" tag was lame. I don't like ActiveX but I get in intranet environments where it can be useful, where the code should be "trusted" and "signed", where you're essentially using a browser to "publish" applications that should probably be desktop applets, or use a native HTML (AJAX?) interface rather than "VB applet on a webpage." That being said, we need an out in the wild, "safe" plugin/viewer model.

Re:Make Acid2 the Default

[alexgieg]

Why not make Acid2 the default?

Because lots and lots and LOTS of pages would break, among other things. Earlier today there was another article in ./ with a link to the full rationale behind this, and to me is makes a lot of sense. Basically, with this tag you can specify a version for each browser on which the site was tested and is known to work well, then all browsers might keep internally working versions of their legacy rendering engines (or a compatibility mode built in their newest engine, whatever works best in each case), and forever in future you'd have old sites being 100% readable in new browsers, no matter how much actually existing "de facto" and "official" standards change or get deprecated/replaced over time. An example from the above link, specifying the page renders correctly in IE 8's engine, Firefox 3's engine and (say) Opera 4's engine:

<meta http-equiv="X-UA-Compatible" content="IE=8;FF=3;OtherUA=4" />

What is there to not like in this? It's a simple, elegant and practical solution to this very real problem. Sure, it could have arrived earlier, but better later than never.

Worst... Proposal... Ever!

[200_success]

Microsoft claims that the X-UA-Compatible flag is necessary on standards-compatible content to avoid breaking IE-specific content. I call BS.

For years, Microsoft has been telling everyone to put version-specific IE hacks in conditional comments, in case IE's behavior improves in future versions. Now that they are finally fixing IE, they spring this X-UA-Compatible "solution" on us, punishing those who have been producing standards-compliant content and rewarding the zombies who have been writing IE-specific code. If your site is standards-compliant, you have to do the extra work to tag it as such, and keep that crufty tag around for the foreseeable future!

If you sat down today and wrote a new standards-compliant browser, it would work just fine with almost all the content and web applications out there. Apple did this recently with Safari. Microsoft claims to have done this with IE 8. Safari didn't need any X-UA-Compatible flag. Why should IE 8 need one?

The only reason IE 8 would need the X-UA-Compatible flag is simply because it is IE 8. If their new browser identified itself as, say, "Microsoft Trident VI" instead, things would just work. Microsoft could still call it "Internet Explorer 8" for marketing purposes, but web developers would know that "MS Trident VI" means IE 8, just as "WebKit 4xx" means Safari 2 (or similar browsers) and Gecko means Firefox (or similar browsers).

Dear Microsoft, here's a sane solution for you:

1. Ditch the X-UA-Compatible flag; it's a stupid idea.
2. Continue supporting HTML conditional comments as you have been doing.
3. Fix the layout engine and the CSS parser at the same time, so that any existing IE-specific CSS hacks become irrelevant.
4. Add support for CSS conditional comments, to give web designers an escape route. Let's face it, CSS hacks are a reality, so we might as well have a tool to do it cleanly.
5. Send this as the User-Agent string: Mozilla/5.0 (compatible; Microsoft Trident VI; Windows NT x.y; ...; Microsoft Internet Explorer 8.0; ...). Any server-side code doing browser sniffing, not seeing the "MSIE" string, should send a standards-compliant response. User-Agent strings have never really been logical anyway -- IE started this mess years ago by sending the "Mozilla" string, and Opera continued the trend by optionally sending the "MSIE" string -- so additional games in this area wouldn't do any more harm to the Web.
6. In JScript, navigator.appName should return 'Microsoft Trident', and navigator.userAgent should return the string above. Client-side scripts doing explicit browser sniffing, not seeing the "MSIE" string, would suppress their legacy IE hacks.
7. In JScript, document.all should evaluate to false (although expressions involving document.all can still behave as in older versions of IE). This approach worked for Mozilla, and it will work for Microsoft too.

As you see, it is possible to fix IE in a backward compatible way without introducing a X-UA-Compatible flag. The chances of Microsoft taking these steps is almost nil, since it places IE 8 on an even playing field with other standards-compliant browsers. That's why they are proposing X-UA-Compatible -- they can claim to support web standards while knowing that web developers will find it easier to muddle along than to use their stupid flag.