Update on the Compatibility View List in Internet Explorer 8
I’ve written a few posts about the Microsoft-supplied Compatibility View List on the IEBlog, calling out the what, how, and why of the feature. I wanted to take this opportunity to bring the community up to speed on what’s transpired since Internet Explorer 8 released back in March of this year and talk a little bit about the future actions planned for the list.
The Story So Far…
Let’s start with a quick recap of the feature... by default Internet Explorer 8 displays web content using its newest, most standards compliant mode. The problem is that some of today’s web pages expect the older, less interoperable behavior from Internet Explorer , handing this latest version of Internet Explorer code meant for older releases of the browser. The result is web pages that might not function correctly in ways ranging from just looking a bit misaligned to not working at all. During the Beta cycle, we introduced the Compatibility View button, which allowed savvy end-users to resolve compatibility problems they might encounter as described above. Despite all of our activities around site outreach, we saw telemetry data that indicated users still had to use Compatibility View in the course of normal browsing. Of particular concern was button use on popular / critical (banking, government, etc…) sites that users rightfully expected to “just work” in Internet Explorer 8. To give users the best possible experience, we combined telemetry data about Compatibility View button presses with other feedback sources – customer-filed bugs, Report a Webpage Problem data, our own compatibility testing, etc… - to create a list of sites that were likely best displayed in Compatibility View. The list’s not enabled by default - users must opt-in to the feature (known simply as the Compatibility View List or Compatibility List, in other documents) as part of the first run experience or later by selecting ‘Include updated website lists from Microsoft’ at Tools -> Compatibility View Settings. For those that chose to do so, Internet Explorer 8 displays sites on the list in Compatibility View rather than the default “best standards mode”. In other words, it’s as if the user pressed the Compatibility View button for sites on the list with the benefit that the end user avoids having to first experience a website compatibility failure to make the determination that these particular sites are best viewed in a non-default manner. You can view the list currently available on your Internet Explorer installation by typing ‘res://iecompat.dll/iecompatdata.xml’ into the browser’s address bar.
Compatibility View List Updates Since Internet Explorer 8’s Release
Though the originally stated list update frequency was about every two months, we’ve actually kept a brisker pace, delivering an updated list about every month. There are a few reasons a faster cadence immediately following Internet Explorer 8’s release has made sense –
- To be extra-responsive to end-user and site administrator feedback. The Compatibility View List is still relatively new and we wanted to be as agile as possible in responding to list edit requests.
- To align with Windows 7’s Release Candidate build. The Internet Explorer team shipped a Compatibility View List update in May specifically to coincide with Windows 7’s Release Candidate; prior versions of the Compatibility View List were only available for Windows XP and Windows Vista (and corresponding server versions).
Going forward, we expect to return to the originally stated cadence. A spreadsheet, available from the Microsoft Download Center, provides transparency into the changes that have been made to the list since its creation. The spreadsheet also contains targeted guidance for sites on the list including step-by-step instructions for performing compatibility testing with and without the Compatibility View List active and the list removal process.
Changes to the Site Removal Process in Upcoming Compatibility View List Updates
Since the list’s inception, the criteria for site removal has been site owner request (process documented here). Going forward, we’re adding a second way that sites can get removed from the Compatibility View List: basic user experience testing.
For several months now, the Internet Explorer team has been doing basic user experience testing for all sites listed on the Compatibility View List. The test methodology is straightforward: in each test pass a tester starts at the home page of a site and examines a set of pages that follows the core user experience for that website. For example, on a video sharing site the core scenarios include watching a video, rating a video, commenting on a video, sharing the video link with a friend, etc… and the tester will browse around the site completing each operation. On each page visited, testers check for visual and functional issues by performing comparisons between Internet Explorer 8 modes (Internet Explorer 8 Standards and Compatibility View) and between browsers. Doing these comparisons aids in determining what working / not working looks like, which isn’t always obvious on sites / pages the tester isn’t super-familiar with. A grading system tracks the type and severity of problems, ranging from ‘no problems found’ to ‘scenario doesn’t work’. Subsequent test passes combine revisiting pages that were previously identified as having compatibility issues as well as augmenting with new pages.
The question of how much of a site one needs to test to determine compatibility is a difficult one. While it's somewhat straightforward to prove the presence of a compatibility problem, it’s decidedly
less so to prove the absence of one. In other words, if a tester finds a compatibility problem, there’s a problem. But, if a tester doesn't find a compatibility problem, does that mean there isn't a problem or that the tester just didn’t visit a page that happens to demonstrate one? By charting the compatibility “scores” of the tested sites over time and by traversing a different set of pages in subsequent test passes, we’ve grown more confident in our ability to gauge the type of compatibility experiences Internet Explorer 8 users are likely to have independent of the Compatibility View List.
Conclusion
With the next Compatibility View List update you’ll see a new designation for site removal in the tracking spreadsheet – “Removed per Microsoft testing” - indicating that our test passes have not found a compatibility issue for some time and so we’re removing that site from the Compatibility View List. We’ve stated previously that we view the Compatibility View List as a short-term solution and believe that adding this additional site removal criteria helps us achieve this end while at the same time ensuring that users continue to have a great compatibility experience.
Scott Dickens
Program Manager
Comments
Anonymous
July 21, 2009
" For several months now, the Internet Explorer team has been doing basic user experience testing for all sites listed on the Compatibility View List. " This must represent a huge, collossal amount of time, typing, energy. My deepest belief is that none of this will achieve anything worthy, solid. Microsoft needs to assist web developers on the issue of upgrading their webpages+websites to comply with W3C web standards (valid markup code, valid CSS code, best recommendable coding practices, etc) in MSDN documentation, with useful, helpful assisting softwares to upgrade web pages. This can be done. This has been done. Once major "issues" with IE browser have been fixed, then proper documentation and useful web authoring softwares need to follow-up. Anything else (a broken-page-switch-to-compatibility button, checkbox settings, meta-tag, download list, manage list, etcet,ect) is just not going to succeed in the long run. regards, GérardAnonymous
July 21, 2009
<<<My deepest belief is that none of this will achieve anything worthy, solid>>> Who said you get to say what is "worthy"? I can use IE8 on the badly written sites that I have to (like my bank) without having to keep a virtual machine around. Sure, it would be nice if the bank just made their site work right, but that's not MY problem to fix. I like having a browser that works with the sites I need it to work with.Anonymous
July 21, 2009
Chris, your post is one of an user. I'm not saying it's illogical or a fundamentally wrong one. Try to understand my perspective here: web, forward-compatibility and interoperability. What's the best solution in the web, for the web, regarding the web here? A pair of pink glasses for everyone? Do you want others to walk or are you only going to offer all of them more or less well-designed crutches? .. and for how long you intend to do just that? The web written with MS-FrontPage and MS-Word HTML export. As soon as 2001, HTML Tidy was already capable of processing, sanitizing (up to a certain degree) such webpages. More than 10 years later/after FrontPage Express, nowhere do we see any shadow of such capability in Microsoft's plans or products or software so far. Zero plans of this sort. No tools like "A real validator" either. No announcement, no horizon. Even IE Blog webpages (even when specifically talking about upgrading to IE 8) are triggering IE 7 so-called standards mode (called standards mode in Developer tools but called strict mode everywhere else by IE Team people: another unexpected source of confusion). Just try to explain that to any web author/developer! Even book authors on web development will need to do a lengthy chapter on this. If Microsoft can not upgrade the IE Blog website to use/trigger IE 8 default and best web-standards-compliant rendering mode, then how in the world are you going to invite or convince others (hundreds of thousands) that they should upgrade their websites? On the very day of the release of IE 8, march 19th 2009, the IE Blog webpage had over 1000 validation (markup and CSS code) errors. And you want or ask shamelessly others (thousands) to upgrade their websites (millions) and their webpages (billions)? Does that make sense? How many IE team members besides Chris Wilson have personal websites (or personal/professional blogs) without validation markup errors and CSS errors? How many webpages at MSDN dedicated on web authoring, web development, best coding practices tutorials, etc. do not have dozens and dozens of errors (in the code, in the examples, etc, etc.)? None. It's been like this for more than a decade, you know. If over 99% of IE users are using IE 6 or higher, then why are you still relying, using, promoting document.all and the proprietary and non-compliant stuff like that in MSDN articles, MSDN examples, MSDN code? There is such a thing as being consequent, being coherent. There is such a thing as promoting what you want/believe by "practicing" what you "preach". "without having to keep a virtual machine around." Exactly what I said before. IE 8 is a 3-IE-rendering-engines into 1 browser. It's even more than 3-in-1 as you have emulate modes inside versions 7 and 8, so-called strict mode, so-called IE 7 standards mode, etc... It's very confusing; it's quite complex. Meta-tag, conditional comments, user-agent strings, etc. More modes, more names, more buttons, more switches, more engines, more lists, more managements, more settings, etc... and the source, the origin of the real issue remain the same. compatMode is incompatible with documentMode on top of all this: a total non-sense. This was denounced a long time before IE 8 RC1, months before RC1. Try to explain this (compatMode and documentMode and then that the 2 are incompatible) to ordinary web authors, ordinary admin of websites. Good luck! I know of web authors who left a bank as a customer and when asked why they leave, they answered in the form: non-web-standards-compliant webpages and website. "but that's not MY problem to fix" In the final instance, it's the bank's problem. And I say that MSDN, Microsoft IE team have a share of responsibility with that bank's website. regards, GérardAnonymous
July 22, 2009
I was hoping to continue helping with window's 8 or 9 lets just start 9 jjkAnonymous
July 22, 2009
There are a lot of major sites still on that list, including Google. :)Anonymous
July 22, 2009
Why don't you use an automated approach to testing sites using bing's indexing? I.e. render every page using Super Preview and then do a screen shot of each, and compare that with an algorithm just like those used for finger print analysis. That way you can go through and update the entire web in your list, and every page on every site without human intervention. Further it will be way more accurate than your current approach because the issues will be obvious. And javascript errors you can compare the browser error messages on every page and see if there is a difference. On those pages that there is, flag for a human to test it.Anonymous
July 22, 2009
@JohnGalt: We use various types of automation in the testing process. However, just because a screenshot looks different does not mean it looks /worse/-- humans have to triage what is different AND "broken" vs. what just renders slightly differently. Rotating advertising and dynamic content, etc, make automated analysis more tricky.Anonymous
July 22, 2009
@JohnGalt - unfortunately it isn't that easy. For one, the way a user interacts with a site/page will do any one of a million things in JavaScript / CSS that superpreview or any snapshot tool just won't handle. If nested deep in your sites code is a call to document.getElementById(someVariable) and it happens to be in a "chunk" of code that only IE sees... then what it returns in IE8 Compat mode vs. what it returns in IE8 Standards mode is VERY, VERY different. In my sample above.. in compat mode a DOM element would be returned... in IE8 Standards mode it would return null. Since any tool scanning the site would not be able to tell if code was accurately sniffing the IE6/IE7 browser out there is no way to tell if the site would break or not in IE8 standards mode. In fact in some cases it might not fail, where an element has the same value for both the name and id attribute. I'm actually fairly impressed with how MSFT is handling this whole migration... by default IE8 Standards mode is on... then based on telemetry data they determine which sites really aren't ready yet (by volume) and auto-tweak them behind the scenes to serve them up in the compat mode. Then when the site/app developer is ready to go live with full IE8 standards support... a process is followed to be removed from the list. It was a lose-lose situation when IE8 came out in terms of do they go Standards by default, or Compat by default. Either way people would complain. Thankfully they went the Standards route, which encourages sites to get ship-shape and up-to-par with today's standards so that the Web can move forward. I don't often give the IE Team Kudos... but this was a good decision and I back them 100% on it. SteveAnonymous
July 22, 2009
The comment has been removedAnonymous
July 22, 2009
The comment has been removedAnonymous
July 22, 2009
http://msdn.microsoft.com/en-us/library/ms537505%28VS.85%29.aspx "For development purposes, the file://protocol is allowed from the Local Machine zone. Otherwise, the XMLHTTP request can only specify URLs with the same port and protocol method as that from which the page is served." Is this something you guys changed from 7 to 8, because the documentation refers to 7. Additionally, i'm not seeing where on http://msdn.microsoft.com/en-us/library/ms536648%28VS.85%29.aspx it says that the sURL is restricted to only HTTP and HTTPS (it makes sense, except for the prior contradiction).Anonymous
July 22, 2009
The comment has been removedAnonymous
July 22, 2009
@Frusterated Person: Thanks for the link. Looking at the IE7 sources, the restriction to HTTP/HTTPS is there as well. I'll file a bug to have the documentation updated; it was likely accurate during one of the IE7 betas but not updated for the final release.Anonymous
July 23, 2009
"If nested deep in your sites code is a call to document.getElementById(someVariable) and it happens to be in a "chunk" of code that only IE sees... then what it returns in IE8 Compat mode vs. what it returns in IE8 Standards mode is VERY, VERY different. In my sample above.. in compat mode a DOM element would be returned... in IE8 Standards mode it would return null." It would, because a rendering of Standards mode will throw an error in this case in javascript whereas compatibility mode wouldn't, thus you'd be able to compare the javascript error as I suggested and volia, you know that there is an issue, or at least a site for a human to test against.Anonymous
July 23, 2009
The comment has been removedAnonymous
July 24, 2009
The comment has been removedAnonymous
July 24, 2009
The comment has been removedAnonymous
July 24, 2009
Didn't know where to post but here. Just bought a 2010 Fusion with Sync and the site is recommending "For the best experience, we recommend using a supported browser". Hey I am using IE8 - the best browser out there! http://www.syncmyride.com/Own/Modules/Intercepts/InterceptIOP.aspxAnonymous
July 25, 2009
@bob e: If you use the "Compatibility View" button in your browser's address bar, the Ford site will stop suggesting that you use IE7.Anonymous
July 25, 2009
- Is it necessary to use "Compatibility View" button in IE8 (for now), so we can expect resolutions of some CSS bugs in next IE9?
- Exists a way to report some sites in Compatibility View List? Thank you for your efforts.
Anonymous
July 26, 2009
That was a long list I don't think many people have the time for that.Anonymous
July 26, 2009
You could use automated tools also..Anonymous
July 27, 2009
I love the irony of IE8 breaking sites and sending users to other browsers that just work. Love it!Anonymous
July 29, 2009
The comment has been removedAnonymous
July 30, 2009
Hey IE team, the webkit [http://webkit.org/] stuff is opensource - you could rebuild a good browser using that right? All is not lost. That being said, I'm sad that the sites I build for my clients don't work across the breadth of Internet Explorer releases - it really leaves me no choice but to instruct my clients to use a more stable browser and in turn inform their constituents to do the same. It's almost like you're engineering continued loss in market share for your software by poor management decisions. [I certainly won't blame the engineers, I happen to be one and know that management makes the poor choices that end up in development more often than not] Some constructive points: Being a developer I become bogged down and frustrated with having to make structural changes to applications that worked in previous iterations of your application. Couple that with the challenge of building innovative web applications, and ensuring compliance with other operating systems and their respective browsers, and I quickly lose profitability in an already challenging market. The corporate policy of ensuring non-compliance with one's competitor's in order to force a market/usage share by duplicating potential purchase points for controllers[ie web software], and support work load for IT is not a good long term solution, or wise/ethical from a social-economic point of view. It's good capitalism in a short term stance, but last I looked you guys are going to be around a while. As it stands you have a huge new generation of young people that are steering further and further away from some of your products - the long term effect is obvious. I write complex web applications for fortune 100 companies and others - some of which rival MS in annual earnings. good luck.Anonymous
July 30, 2009
montana, none of your "constructive points" is constructive in any way. Why waste time writing it and force others to waste time reading it?Anonymous
August 03, 2009
@seth: thanks for that, I'll log that away. it is constructive to consider long term impact of development decisions. If you care to explain how it's not, I'd love to hear it. sorry I forced to read - it must be challenging for you...