Weblogs: Web Standards

Internet Explorer 8's compatibility blacklist is a minefield. There are serious shortcomings and issues which, if IE8 is launched in it's current state, will be as embarrassing to Microsoft as the launch of IE7 was back in 2006.

On Thursday when I wrote about IE8's Blacklist forcing standards opt-in, it seemed a simple choice of supporting one or both of IE8's standards and Compatibility rendering modes. Or if your site appears in the IE8 Compatibility Blacklist, then you needed to do nothing since you got the Compatibility Mode rendering which is exactly the same as IE7.

That is what the IE Team are saying. But in practice it's a different story.

Emulating IE7

When a blacklisted page is rendered, IE8 switches to a Compatibility View (document mode EmulateIE7). It is not IE7 proper, but meant to emulate IE7 rendering. Except it doesn't. So far this week I have witnessed two pages that render fine in IE7 proper but have rendering issues in the Compatibility View

Microsoft's argument for the Compatibility View blacklist is to give their browser users the best possible experience when they find a high-profile site that doesn't render perfectly in IE8. But the assurance that Compatibility mode functions the same as IE7 isn't holding.

Because of the rendering differences and issues, websites listed in the Compatibility blacklist will have to test in IE8's Compatibility View browser (EmulateIE7) as well as IE7. The two are not the same thing, and not 100% compatible.

Where is the real IE7?

Maybe we could add a meta tag to force the IE7 document mode instead of the EmulateIE7 document mode? Well that doesn't work either. Browser testing a high-profile page today demonstrated that the IE7 standards mode in IE8 isn't 100% compatible with the real IE7 either!

There are obvious display errors, around DOM Scripting animation and elements styled with position: relative. (position: relative is a well-known and heavily-used trigger of hasLayout, solving many IE6 and IE7 rendering issues).

At face value the IE7 rendering engine bundled with IE8 isn't functionally identical to the IE7 browser. So if triggering IE7 standards mode is how sites are going to deal with IE8, then testing in both IE7 and IE8's version of IE7 is mandatory. That is still an extra browser to support, despite the IE team's claims.

Developing with web standards

Sites built to web standards should work in Internet Explorer 8. Developers might feel that there's nothing to do, but unfortunately I believe they have more issues to deal with. The sanest path, even for them, is to opt in to IE8's standards mode.

Sites that make no declaration of their preferred rendering mode will be affected by both being added to the Compatibility Blacklist, or users having access to the "Enable Compatibility View" toggle. That means testing in IE7 and IE8 isn't sufficient, developers have to test their sites in IE8's Compatibility Mode - since that isn't rendering pages like IE7.

So opting into IE8's standards mode is practically mandatory, otherwise the developer is dealing with a minefield of rendering issues and differences.

Developing on a local network

A particularly nasty pitfall to remember is that by default, Intranets or websites running on the private range of IP addresses (e.g. 192.168.*.*) will be defaulted to IE8's compatibility mode. So you can't assume that a page running on your local network that works in IE8 will still work when it moves live.

Again in this case, the only sane approach is to opt-in to IE8 standards rendering mode.

But it's all user opt-in?

One of the arguments being used in support of the Compatibility blacklist is that it isn't enabled by default. A visitor has to select that option. This is meant to reassure us that the problem we are facing isn't such a big deal, because not all that many people will select that option.

Earlier today we installed a copy of IE8 on a fresh new VMWare image and the install offered a "Default Install" or "Custom Install" dialogue box. Neither was initially selected, and the user has to select one of those options. The Default option included subscribing to the Compatibility View, while the Custom option included a piece of text that said something along the lines of You will be able to customise every option one at a time. For typical end-user installations of IE8 they will select the easy and quick option of "Default install", and so a high number of these end-users will have Compatibility View on.

It's a choice between the lesser of two evils. Neither of them are particularly wanted. Just the Default option looks to have less hassle.

The only sane approach for a website is to trump the end-user selection and opt into one of IE8's standard rendering modes.

Blacklisting top-level domains

Compatibility blacklisting by top-level domains hurts large organisations operating on multiple subdomains. These large organisations have separate teams supporting the separate sites, each have their eccentricities and development styles. What is a good rendering mode for one subdomain may not necessarily be the best choice for another subdomain.

The compatibility view conflict can only be resolved by each subdomain explicitly opting into their preferred standards mode. Otherwise one high-profile subdomain with a rendering issue will impact all the other subdomains. Which means subdomains that are working perfectly in IE8's default rendering mode will still have to separately test in IE8's Compatibility view just in case another subdomain triggers a Compatibility Mode Blacklisting.

Looking at the evidence posted in the IE8 blog, a rendering error of the stock price charts on Google's Finance website is sufficient reason for Microsoft to blacklist google.com. Every other web presence that Google hosts on other subdomains, including Search, GMail, and News either has to explicitly opt-into a different rendering mode, or take their chances in the Compatibility Mode.

That means the only viable approach for organisations running multiple sites on subdomains is for each subdomain to explicity opt-in to their chosen IE8 standards rendering modes.

Dealing with IE8

So what's an organisation to do? Internet Explorer 8 has four different rendering modes (IE8 standards, IE7, EmulateIE7, IE8 quirks), and not a single one of them is 100% compatible with IE7.

The choice is starkly obvious; either pick one of the IE8 rendering modes and explicitly opt-in to it using a meta tag or HTTP header, or refuse point blank to support IE8.

Opting into standards

Opting into a standards rendering mode is the only viable solution. Either you pick a rendering mode that best suits your pages, or Microsoft will pick one for you.

I wasn't kidding when I said that IE8's Compatibility Blacklist essentially forces listed websites to opt into standards compliant rendering. Except today, I'm more convinced of that than ever before. Any site that could potentially be listed in the IE8 Compatibility Blacklist has no real practical choice apart from opting into a rendering mode. It's either that, or accept the Russian roulette of the supposed IE7 rendering modes in IE8.

Microsoft have made an end-run around the web standards movement. High-profile sites in a difficult quandary and there isn't an alternative solution out there that fits in with the spirit or philosophy of web standards. The only approach that makes any practical sense is for a website to explicitly opt into their chosen standards mode - the very thing we rejected one year ago.

That is a difficult pill to swallow. We are clearly not ready for IE8.

---

[ Weblog | Categories and feeds | 2011 | 2010 | 2009 | 2008 | 2007 | 2006 | 2005 | 2004 | 2003 | 2002 ]