I was surprised that when I got back from vacationing in Hawaii to read a Slashdot post by Jeff Reifman about an article Paul Thurrott wrote…last year. I read Slashdot regularly, and it didn’t make sense; not only is this old information, but it’s not even factually correct (which I’d like to think is a requirement for Slashdot posts).
Jeff did later figure out the article was from last year, and edited his post. And others have pointed out that Paul has made several posts since last year about IE7. I’d recommend reading them, such as this one from (THIS) June reviewing IE 7 Beta 3, which seems to indicate Paul thinks we might be heading in the right direction.
As for IE’s CSS compliance, I’d love to have a honest, straightforward, unbiased statement of exactly where we (and other browsers) are – despite the fact that I know we would be behind today. Unfortunately, I don’t think that exists; any “statistical analysis” of support is by nature biased. How do bugs count against you? For example, one of the big developer complaints in IE6 was that we didn’t support “background-position: fixed” on non-BODY elements – but we passed the W3C CSS1 test suite, because we supported it properly on the BODY element. And we support the ‘float’ property, and pass the set of tests in the CSS1 test suite – but even in IE7, we have some bugs in interacting with width and height, which is one of the contributing factors to us not passing the Acid 2 test suite. Your personal view may be that that’s as bad or worse than not supporting ‘float’ at all, but a lot of designs in use on the web today require floating.
The site that Jeff’s post referred to (developed by David Hammond) is weighted in a way that makes IE in particular look bad (not particularly surprising, given some of the other pages on the site) – for example, it dings our support of each CSS property, one at a time, simply because we support a proprietary “CSS expressions” feature; similarly, the fact that we don’t support the ‘inherit’ property value across all CSS properties is counted against us one for each property, not as a global feature as it would be implemented and used. Most unfortunately, there are no more details on many of the problems David encountered, or test cases that my team can test against. When I contacted David a year or so ago, he couldn’t give me any further details, so I’m not even sure how we make progress against that site. Solid test cases we can access and bug reporting would help – which is why we have a public bug database. I’d also like to turn comments like “IE 6 and IE 7 failed to render even basic columnar layouts in CSS” in to solid work items, but I don’t understand the problem – much of the web uses columnar layouts that work in IE. Is this a request for CSS3 multicolumn support, or a narrow bug with the way you’re trying to do columnar layouts?
The one thing that really burns my personal toast is that we’ve been working hard to improve our standards support in IE7, and I believe it is simply wrong to think that we’ve only moved the needle 2%. In fact, we prioritized IE7 around 3 things – security, end user experience, and standards improvements in the platform. When I look back at the work my team has done in the platform, we have done only these things. No proprietary features added, just standards improvements. (Look forward to an upcoming IEBlog post from Markus Mielke listing out the CSS changes we’ve done in IE7.) I feel that we’ve addressed the biggest problems and shortcomings from IE6 for web developers and designers, and we’re hard at work shipping IE7 and getting ready to doing it again in the next release. As I previously stated, our goal is to make the lives of web developers better by improving standards support in IE. I think we’ve done a lot in IE7 to do just that, and I’m looking forward to doing even more.