Archive for December, 2008

To be honest I wasn’t really expecting them to release this, considering they only recently posted detailing their release schedule from now until launch (which this Partner build wasn’t included in).

However, like a few others I was concerned that they weren’t going to release another Beta, so I’m pleased they’ve released this version which bridgees the gap between Beta 2 and the Release Candidate which should be with us by the first quarter of next year.

They’ve literally only just notified me of this private build, so I’ve only had time to run through the test cases for the bugs that I spotted and logged on my own IE8 Bugs page; after some initial testing, it appears they’ve fixed five out of the twelve bugs that I spotted in Beta 2.

It seems all I talk about on this blog these days is IE8; if you don’t have any interest in IE8, I apologise.

Upon checking my visit logs tonight, I discovered I was quoted on the ieblog referring to some things I mentioned in . Subsequently, Scott McIver from the IE team responded with some interesting comments.

In reponse to the ‘assumption’ I made where I described what telementary data the list will be made up from, Scott suggested that I had misenterpreted what will actually happen when in fact what will happen is, … a list of super-important sites is compiled (based on 3rd party survey data). We then look to see if users are having compatibility failures on those sites and, if they are, contact those sites and add them to the list. What I don’t understand is why they’re planning to break down into this ’super-important’ tier. Even with 3rd party survey data, it’s still a very subjective criteria; it’s an obvious fact that different usergroups will deem different types of sites to be most important – it’s a personal thing, at the end of the day. To me, it seems a no-brainer for them to base their list on sites (top 1000 or so) that the highest frequency of users perform a compatibility-switch on- this criteria seems far more relevant in this context.

Show me the list, show me the list

Perhaps a more effective means of finding out whether your site appears on this list, is to make it public (Update: if you want to find out the contents of the active list, you can navigate to res://iecompat.dll/iecompatdata.xml in your address bar), rather than waiting for Microsoft to email you about it? On top of this, Microsoft need to provide developers which a clear means of contacting them regarding removal of their site from the Compatibility View list – currently, I see no way of doing this.

Lack of CSS 2.1 support and it’s probable effect on Compatibility View

I’ve been pretty busy this weekend filing (I’ve found in just one day). Just recently I’ve become acutely aware that the final release of IE8 won’t fully hit CSS 2.1 support, whether it’s because a spec implementation is buggy, or they’re not going to bother implementing a spec full stop. This lack of support got me thinking about the impact this will have on the users interaction with Compatibility View; even though many of the bugs I’m coming across are fringe cases or features that aren’t currently being used on a large scale (can be blamed on browser support, I’m sure), there is lack of support for (or bugs relating to) features that are commony used. These issues will of course result in a substandard page layout, and my concern is that end-users will be tempted to perform a compatibility-switch in the hope that it fixes the layout, when all it’ll do is either look the same or worse – OK, compatibility-switching won’t fix the lack of support for the print media descriptor when used with the @import rule, but you catch my drift.

Incorrect use of Compatibility View

I saw this post, in which we get a better insight into what the IE team were talking about when they said high-volume sites weren’t working for end-users with IE’s new standards compliant default. Scott describes how styles that should be specific only to IE7 (to work around it’s layout bugs) are also getting applied to IE8, on the popular MySpace.com site. For example, they have chosen to use the gte IE7 (greater that or equal to IE7) operator which of course means that IE8 applies these styles too. The underlying issue here then, lies with authors making irresponsible decisions relating to which operator a conditional comment uses not that these sites aren’t coded to be standards compliant. So, perhaps in hinds sight, Microsoft shouldn’t have implemented the greater than operator in the first place.

I can in fact, see this being a problem across all future IE versions; for example, when we get around to IE9 (which will hopefully not include Compatibility View), sites like MySpace will continue to break in the same way they’re doing now if those site authors don’t update the Conditonal Comment operators they’re using.

On a side note, I had a little chuckle when reading this post from one angry developer; based on his use of uppercase text, asterisks for emphasis, and generaly formatting, I’d hate to meet him in person on a bad day!

Aside

This random made me laugh. I didn’t particularly want to create a whole new post just to showcase , so I’ve stuffed it in this one

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