Compatibility View stuff

It’s been a while since I’ve posted about the Emulate IE7 Compatibility View feature.

My first gripe…

Granted, the position of the ‘Emulate IE7′ button in Beta 1 was ugly as hell, I can only assume that this button re-posiiton (and re-size) goes to show the apparent lack of thought that has gone into how users will identify with what this button actually does. Instead of a fairly prominent ‘Emulate IE7′ button positioned near the top right of Beta 1, the IE team have placed the new UI button for Compatibility View in an inconspicuous area to the right of the address bar. Chris Wilson has said, however , that they may move the button position based on user feedback. The underlying issue though is that the target audience of IE8 won’t have the first clue what all this fuss is about.

Compatibility View based on user feedback?!

The main reason for me writing this post is down to an article the IE team released yesterday relating to a new extension of Compatibility View, that will make the experience of defaulting to standards mode better for the end user. Essentially they collect the data, relating to what high-volume sites other users clicked the Compatibility View button on (i.e which TLDs most commonly prompt a user to manually switch to Compatibility Mode). A list of the TLDs that prompt the highest number of switches is compiled, and then users who download the next update of IE8 (or install the Beta of Windows 7) have a choice as to whether they want to opt-in to the aforementioned list of sites that should be displayed in Compatibility View (check out the ).

What prompted the IE team to implement this ‘community-powered’ solution?

Apparently, according to the article, high-volume sites such as facebook.com, myspace.com, bbc.co.uk, and cnn.com have been specifically flagged (presumably as a result of this collated user data) as not working correctly in the standards compliant default mode. As this user data has come from Beta 2 (and perhaps more worrying Beta 1?), which still has an alarming amount of rendering bugs still active, it’s highy likely that what end-users are actually seeing are Beta 2 (or Beta 1’s) rendering bugs, not as a result of a badly-coded website which relies on IE7’s quirky layout rendering.

Arguably, the most worrying situation for authors of these sites would be if MS decided not to refresh the data that the TLD list is based on, once the release candidate is distributed. Not refreshing this data (i.e wiping the data collected from the two Betas), would mean that authors of sites that appear in the ‘blacklist’ would presumably have to use the version targeting <META>/HTTP Header together with the newly introduced IE=EmulateIE8 value to remove their site from this blacklist – I presume this since there was a similar mechanism proposed back in August. So we are back to a similar scenario to the one where it was proposed Compatibility Mode be enabled by default, where even though a site is standards-compliant, the <META>/HTTP Header reset will need to be added by default to prevent these standards-compliant sites being viewed in Compatibility Mode.

I am still intrigued as to why sites such as Facebook, BBC etc were flagged, so I did a quick browse in Beta 2 and couldn’t find one rendering issuze on any the sites mentioned- I’d suggest that the apparent issues that end-users have experienced are down to performance (Javascript/AJAX) issues as opposed to layout bugs.

How does this new feature tie-in with the user-specific blacklist

The latest post doesn’t actually mention whether this ‘community-powered’ blacklist will work alongside the user-specific blacklist mention in the initial article on Compatibility View. I imagine that if they were to run in paralell, then the user-specific blacklist would overwrite the community-driven one.

Overall, an interesting concept I’m sure you’ll agree. And this after Chris Wilson thinks Gerard was overplaying how many people will push that [Compatibility View] button