Compatibility List FAQ

Original: Compatibility List FAQ

A few weeks back, we announced Compatibility View improvements available in the Release Candidate build of IE8. As you'll remember from my previous post, users can choose to receive a list of major sites that are best viewed in Compatibility View. When navigating to a site on the list, IE8 will automatically display the site in Compatibility View without requiring the user to press the Compatibility View button. There's been a lot of really good discussion around this and a few common questions have bubbled up. I've attempted to roll-up answers to these common questions in one easy-to-find

Why is my site on the compatibility list?

In short, we've received customer feedback via product telemetry, bug reports, Report a Webpage Problem, etc… that users are encountering compatibility issues while browsing your site. This data shows that users are choosing to view your site in Compatibility View rather than Internet Explorer's default, most standards compliant mode. Your site has high traffic volume (in your region) and having a working, functional site in IE8 ensures a significant number of IE8 users will have a great experience.

Can you give me an example of what's not working on my site?

The telemetry data we receive is normalized, aggregated data for a top level domain. It doesn't tell us the exact reason users have compatibility problems nor does it provide us with the URL / page that caused users to switch to Compatibility View. In other words, the data isn't actionable for driving IE8 compatibility test efforts as it can't pinpoint the exact content that caused a compatibility problem. It only tells us that there was a compatibility problem.

You might ask, why use telemetry data at all given this limitation? It turns out using telemetry is an extremely accurate capture of user browser preferences – more accurate than say an IE team member taking a look at a site and determining if it's broken. It's objective measurement v. subjective supposition (would users click the Compatibility View button if they visited this web site?). Additionally, using product telemetry allows us to scale well beyond the number of sites and pages our internal test team can handle.

Data from other product support channels such as bug reports and Report a Webpage Problem data does often have exact URLs and repro steps. And combining the two, telemetry + other sources, gives us really powerful and useful information. We honestly don't have an example for every site compatibility issue out there – we just don't scale to that level of in-depth analysis for every website IE users visit - but I have provided a few examples that are representative of the types of issues we've seen:

Site: www.mapquest.com, view the map of a city, and click on traffic, (direct link)

Issue: Traffic does not show on the map. The selector syntax in use by the page for VML (e.g. v\:*) is not valid per CSS 2.1 and therefore IE8 Standards Mode does not accept it. 

Site: www.myspace.com

Issue: Top banner on myspace.com front page isn't centered. Myspace worked around issues with the 'clear' property in IE7 by feeding that browser version unique CSS styles via Conditional Comments. Those styles are no longer required in IE8 and cause the described behavior.

Site: www.cnn.com

Issue: At the bottom of most every page is an empty white box – an IFRAME that correctly displays in IE8 but that's not shown in IE7. (NOTE: other browsers don't show the issue because they're not handed the same markup as IE).

 

Site: www.google.com, go to finance and search for a stock quote (direct link)

Issue: The stock tracker chart is clipped on the right side. The page uses invalid HTML mark-up that is being fixed up differently in IE8 Standards Mode than it was in IE7 Standards Mode.

 

Does TLD mean 'microsoft.com' or 'msdn.microsoft.com'?

The level of granularity of sites on the Compatibility View list is 'top-level domain' (TLD). 'Top level domain' means 'microsoft.com' in this example.

The reason that we chose to use TLDs rather than sub-domains was three-fold:

1. We've optimized for a better end-user experience with less compatibility failures and button clicks. The assumption here is that one compatibility failure is bad; multiple failures for what the customer basically thinks of as the "same site" is even worse. For example, imagine that none of the Microsoft properties are IE8 compatible. User visits msdn.microsoft.com to review an article - button click. The article redirects the user to support.microsoft.com - another button click. User then visits connect.microsoft.com to file a bug with us that they have to click the button too often :) - another button click.
2. Storing exact URL / sub-domain doesn't always work well for things like server farms, site structure redesigns, etc...
3. We're avoiding a scalability issue where IE has to synchronously consult a list of tens of thousands of entries prior to each navigation (we need to flip the page into the right mode from the start). Using TLDs keeps the list size manageable.

Given the above, there is a scenario where users encounter a failure on one sub-property in a large, distributed (read: managed by different entities) site structure and switch the web site into Compatibility View and it impacts the entire property. We totally understand that concern and here's how we think we're addressing it. For one, if you use the X-UA-Compatible tag / header, the client loses the ability to put the page into Compatibility View via the button. Product telemetry is keyed off of the button state; therefore, no button == no way for users to press the button and thus signal the site as not being compatible. For another, if your site ends up on the list, you always have the option to opt-out. Per the previous blog entry on the subject –

>>We reach out to those sites (beyond all the other outreach we've already done!) to make sure they know the experience their IE8 visitors have by default and what steps they (the sites) can take to make it better. We also tell them that in the meantime, we're adding their site to this compatibility list and provide instructions on how the site can opt-out. (If a domain notifies Microsoft that it's choosing to opt-out, we remove it from the list at the next scheduled list update.)

When should I make sure my site is compatible with IE8?

We understand the shift towards better standards compatibility with Internet Explorer 8 may take some time to complete for each organization or webmaster. That's one of the reasons we have the Compatibility View feature – to bridge the gap between IE8 release and site support for IE8 so users (of IE8) can still view and use all those sites that worked in older browsers. That said, the time to get ready is now. The last public update of IE8 has been released. Please download it (if you haven't already) and use the resources on MSD

Scott Dickens
Program Manager