On IE8 version targeting
I’ve only met Eric Meyer once, but he’s always seemed to me to be a decent, humane blokeso it’s not surprising that he wrote about the animosity in the debate about IE8 version targeting:
Sometimes what binds us is strong enough that the few differences seem sharper by comparison. That shouldn’t keep us from remembering what we have in common, and the importance of that commonality.
Like Eric, I’ve been saddened by the vituperative tone amongst erstwhile friends lately, and I think Jeff Croft is spot-on to characterise it as a clash of ideologies: pragmatists versus purists. His analysis explains why I’ve found it so difficult to make up my mind, as I’m both pragmatist and purist at once.
I’m a purist who believes in open standards, semantics and accessibility. But I’m also a pragmatist who’s long advocated using conditional comments which are IE-specific and against the HTML spec. I’ve also advocated deliberately breaking validation in order to cater for User Agent Accessibility Guidelines shortcomings in IE.
So I could almost reluctantly accept Microsoft’s idea, although I would have to hold my nose at the disingenuous suggestion that without the IE8 Magic Microsoft Metatag™ (MMM) the web would break (it wouldn’t; some intranets and some crappy browser-based applications belonging to some powerful Microsoft customers would break, but the web wouldn’t). I don’t want to code round the market-leading browser any more, so could hold my nose if the MMM were likely to work—but I don’t believe it will.
Why it won’t work
Firstly, as I’ve written previously in Microsoft versioning: accessibility implications, “freezing the web to IE7 levels consigns much of it to perpetual inaccessibility”. Now, locking people with disabilities out of websites, that is truly breaking the web.
Secondly, what happens when scripting across frames and windows that have different MMMs? It may be that this will work perfectly, but I’ve seen the question raised a few times and seen no answer. (Caveat: there may be an answer posted on a site I haven’t seen, and maybe it’s a non-worry; I’m no DOMscripter.)
Thirdly, I just don’t believe that Microsoft will be able to guarantee that every new version of Internet Explorer will contain within it the rendering engine, scripting engine, HTML/ XML/ XSLT parsers of every single one of its preceding versions, and always guarantee that retrospective security patches applied to the ever-increasing number of codeforks in IE8, IE9, IE10 … IE∞ will not change their behaviour.
This is not because I think Microsoft are evil or incompetent, just that it’s a version control horror that nobody could possibly sustain. One day, they’ll have to cut support for old versionsand then we’ll be back to square one.
So, for purely pragmatic reasons, I don’t believe that the IE8 MMM will work. This does NOT mean that I hate Eric, Molly, Zeldman, Aaron Gustafson, PPK or Chris Wilson: it just means that I respectfully disagree with them.
But I’m also a realist (or as much of a realist as 60s-born leftie accessibility-wonk can ever be), so I’m aware that, whatever I may think (or whatever you may think), it’s likely that this is a done deal, and we’ll see the MMM in IE8.
The future
I’m not going to use the MMM on this website. I’ve moved to an HTML5 DOCTYPE, as IE8 will not default to treating HTML5 as legacy content, and therefore will use its most up-to-date rendering engine.
I’ve done this as an experiment; I implore you do not do this on a production site – no browser can render HTML5, as it’s only just gone into Public Working Draft, so it’s not ready.
I also expect odd things to happen once some browsers begin experimental HTML5 support (for example, HTML4 has the legend element in forms, while HTML5 has additional uses for legend, so who knows how my HTML4 forms will appear in an HTML5-aware browser?)
HTML5 is a long way from perfection (or even completion) and I’ve already had some serious worries about HTML5’s accessibility, but it feels like the future because it tries to address needs of the “application web” while maintaining support for the “documents web” and it will free us from the tyranny of one legacy browser’s rendering engine.
Oh – here’s a health warning: Using the HTML5 doctype prematurely “considered harmful”. Like I said, don’t use an HTML5 DOCTYPE except on experimental sites like this.
(Last Updated on )
Buy "Calling For The Moon", my debut album of songs I wrote while living in Thailand, India, Turkey. (Only £2, on Bandcamp.)
9 Responses to “ On IE8 version targeting ”
I agree with pretty much everything you’ve written; yet I’ve come down on the other side.
I think you’re right: at some point IEx will be so bloated they’ll need to launch a new browser instead, which hopefully will support standards from the get-go (leaving anyone wanting to stick with IE welcome to IE7 rendering!)
I also agree with what you’re saying about accessibility, but I think for the most part these sites that microsoft are afraid to “break” will have accessibility problems anyway, so I don’t think this is making things worse…
Moving to HTML 5 is an interesting idea but I have accessibility concerns there too, so I’ll be using the IE-edge case. But you’re right, it’s nice to be able to disagree without getting all grumpy about it:-)
Hell of a meeting that was, too. One of these days I need to get back over there with some time to spare so we can hoist a glass and talk of fun and silly things for a few hours.
I too experienced the purist/pragmatist dilemma, and I absolutely get where and how you came down on this. Hell, I may one day shift sides, depending on the answers to the questions you list.
@JackP: The sites Microsoft are afraid of breaking are primarily corporate intranets and the like, as far as I’m aware. The correct solution in this situation is to do an officially-sanctioned release of something like Tredosoft’s “MultipleIEs” and allow IE 7 to be run standalone alongside IEx. This can be rolled out by systems administrators as required, _and the rest of the world—those of us living on the *public* Internet—doesn’t have to suffer_.
Of course, to do so would be to admit that IE isn’t nearly so much of a critical embedded OS component as was stated in anti-trust trials, even though we all know that to be bunkum—but to admit it officially would be tantamount to perjury.
@Mo “The sites Microsoft are afraid of breaking are primarily corporate intranets and the like”
It’s not just “breaking the corporate intranets” they’re worried about. There’s a metric bucket-load of software out there that embeds the IE browser control and then fires it’s own hard-coded shonky HTML in there. What happens when the underlying rendering engine changes? Yep, that’s right, the application breaks. It’s a difficult one.
@Olly: This is true, but the solution is broadly the same (though in many ways _easier_ because we’re talking about tweaking software purely within the Windows ecosystem, which Microsoft controls). Give the new IE control a new GUID and keep the old one around. Install the old one by default as part of the setup process if you must. Old apps continue to use the old control with no changes to anything required.
It’s worth bearing in mind, though, that we’re talking about “sites (or web apps, or intranets, or whatever) which both (a) trigger IE 7 standards-mode, (b) aren’t actually standards-compliant, and (c) didn’t use conditional comments so will break for IE 8. The proportion of actual real websites that falls into this category rapidly approaches zero, not least because Microsoft went out of their way to tell people exactly—in no uncertain terms—how to fix their sites when IE 7 “broke” them, and everything I’ve seen suggests that compliance with that is widespread.
In other words, the IE 8 “problem”, barring a tiny handful of sites which don’t come anything close to the “1% of the web” Microsoft is scared of breaking, actually only really affects sites accessed from a tightly-controlled environment—either a corporate scenario where IT departments have the final say on what, how and when things get installed, or restricted to specific Windows applications. In both cases, having the IE 7 engine kicking around separately from IE 8 would suffice, without any need for defaults to change or anything like that.
Those who require that kind of closed ecosystem can keep it; meanwhile, the rest of us—those of us who have spent countless days working around IE’s shortfalls—can carry on building standards-compliant sites with one less thing to worry about, and all those quirks mode sites out there will continue unhindered anyway.
A lot of angst and too much to do about little. Microsoft wasn’t about to tie the IE7 version engine to future versions beyond IE8. That has even become moot with Microsoft’s announcement, today.
[…] On IE8 version targeting […]
Unless I’ve misunderstood something major, HTML 5 is supposed to be backwards-compatible; that is, anything which is valid HTML 4.01 or XHTML 1.0 should also be valid HTML 5 and the serialisation should convey the same semantics to an HTML 5 UA as it would to an HTML 4/XHTML UA.
Assuming my understanding of this is correct, if there’s a situation where an HTML 5 UA differs from the accepted consensus of how an HTML 4 UA should behave, then it’s either a bug in the HTML 5 spec or a bug in the HTML 5 UA.
Of course, this is a tricky issue, because there isn’t a complete consensus on how an HTML 4 UA should behave in some circumstances (this being part of the point of HTML 5), though as far as I know this is far less of an issue where mark-up and scripting are concerned as compared to CSS.
I’ve argued in the past that I believe the HTML 5 spec should have been two separate specifications: one, documenting the state of UAs’ various behaviours as they stand now (which is not an insignificant portion of the specification), and the other defining the new things that HTML 5 brings us. I doubt there’s a lot of point in continue to argue that one, though—although I’m still a little mystified as to why that path wasn’t chosen from the outset, as it strikes me as the logical way to accomplish the two distinct roles that HTML 5 covers.