IE8 standards compliant by default - but not for Tweakers.net
Frankly this really doesn't benefit anyone; our users won't get the best browsing experience on tweakers.net using IE8, and we get locked into IE7-mode for who knows how long without having asked for it. The only way for us to defeat this would be to use their proprietary X-UA-COMPATIBLE switch saying IE=8 or IE=Edge on all of our pages, but that wasn't the promise.
Now Microsoft argues that the compatibility list feature is off by default, but who knows if this will still be the case by the time IE8 ships? Also it isn't clear how one can apply to be removed from this list, and how much time that will take. What I do understand is that updates to this compatibility list will be offered as non-critical updates through Windows Update, so that will probably leave a lot of people with outdated lists in time.
The biggest question I however have at this point is: why are we on that list in the first place? We did receive an email (Dutch) some time ago from Microsoft with regards to IE8-compliance, and even though this email wasn't very useful, it did mention that the 'issues' encountered were merely presentational and not functional. I do know of some minor presentational issues with our site in IE8 but those I deem bugs/regressions in IE8. I also know that Microsoft has fixed some issues post-RC1 that may be related to some of these, but not having any way to test and verify this, nor any convenient way to relay issues to Microsoft (and receive proper feedback), leaves us in a position where it is simply impossible to 'prepare' for IE8 before it becomes final.
So what are the criteria for a site to be put on this list? Is it really just the number of clicks on the 'compatibility view' button? How does Microsoft know how to put that into context with the total number of (IE8)-visitors on a certain site? Do they keep in mind the type of visitors for that site? Do they perform some kind of manual check? What kind of criteria do they use for that? Do they just assume it's the site's fault instead of IE8's? It's all dubious at best...
Our 'strategy' at this moment is quite simple: we serve IE8 the same code and mark-up we serve all other (non-IE) browsers, which is fairly standards-compliant as far as I can tell. If IE8 cannot handle this than the fault must be with IE8 and Microsoft should fix this. Putting us on some kind of 'compatibility list' (which is actually a "not-compatible with IE8" list, but not necessarily a "not-standards compliant list" although Microsoft tries to make you believe it's the latter) is just a blatant insult.
Update 24-02: the lead programmer of Microsoft's IE team has personally contacted me after I placed a comment on the IE blog on how to be removed from this compatibility list. He was actually very friendly and helpful and as per our request made sure we were removed from the compatibility list before IE8's RTM
I can only hope it's a relief to hear that I've since started using Firefox 3.1b2 as my primary browser. I was sick of Microsoft not deeming vulnerabilities "important" enough to fix, or ignoring me altogether. (I'd been browsing with Active Scripting disabled-by-default for such a long time...) Too bad Mozilla, too, will probably be hurt by the introduction of this proprietary flag - even though proprietary headers are very much discouraged, and not intended for use outside of testing.
Compared to what I was used to, it's certainly refreshing to visit Secunia, and take notice of how there are NO open vulnerabilities for the most recent version of Firefox. None!
On a final note; even though Internet Explorer has a terrible track record regarding standards compliance, it's still a browser with more than decent usability. If it weren't for the horrible security response, I would probably still have been using it. Hell, I made it a point not to give in to the n00bs blindly telling me how because was using Internet Explorer, I must be browsing insecurely. Wrong. I tracked vulnerabilities, and worked around them. The consequence of this wasn't so much bad security, only bad usability, as disabling Active Scripting was one of the workarounds, which I never expected to have to use for a long time...
Anyway, this has become enough of a rant already, I hope my story will be of interest to some other self-proclaimed geek. ;-)
Met de header an sich is niets mis (apart van het feit dat met X-UA-COMPATIBLE META-directives voorgaan op de HTTP header wat niet-standaard gedrag is); maar dat het een bepaalde rendermodus forceert is wel iets dat verder in geen enkele standaard omschreven staat en dus per definitie ook niet interoperabel is. Microsoft introduceert een nieuwe quirksmode en dwingt websites hier in door middel van de compatibility list en presenteert X-UA-COMPATIBLE daarmee als een opt-out mechanisme, en dat is kwalijk.Wat is er mis met X-UA-COMPATIBLE?
Comments are closed