I’d like to live in a world where people weren’t killing each other over religious and ethnic differences and where version targeting wasn’t needed. Designing with web standards ought to be enough, and anyone who works on websites should know how to do it. Browsers ought to have near-perfect standards compliance by now, and if they don’t, their manufacturers should switch to folk music.
But manufacturers, including Microsoft, have a weird way of staying in business when their products enjoy a healthy market share (healthy for them, if not necessarily for the market). And even huge companies—for instance, companies like Microsoft—occasionally listen to their customers and try to solve problems related to their products.
To understand version targeting—which we ought to try to do, since Microsoft intends to implement it and hopes at least some of us will opt in—let us examine two different sets of customers that Microsoft’s browser must satisfy.
The quick and the dead
One set of customers—let’s call them knowledgeable designers and developers—strives to create semantic, accessible, standards-based sites. They also, we hope, aim for great design, compelling and meaningful content, usable interfaces, and semi-transparent site architecture.
For this group (wave if you’re part of it), the biggest problem with IE has been that its standards compliance has never matched that of Firefox, Safari, and Opera. Particularly during the long weird years when an unchanging IE6 sat moldering in the corner, knowledgeable developers rightfully moaned that every time they built a site with standards, they had to go in and create workarounds for IE’s deficiencies. Other browsers had bugs requiring workarounds, too—but nothing like IE’s litany.
To satisfy this customer group, Microsoft had to significantly upgrade its browser’s standards compliance—and then keep upgrading it, in frequent increments. With IE7, Microsoft has begun to do that. With IE8, it will go further, particularly where scripting is concerned.
But Microsoft has another by no means tiny set of customers. We might call them the unenlightened. Some are professional developers who should have heard about web standards and accessibility by now, but either haven’t heard or don’t care. This may be because they work in companies that restrict their access to books, conferences, and even non-work-related websites—dim companies with outdated and myopic rules about which browsers and platforms shall and shall not be supported. Let’s be charitable: some of these developers work exclusively on platform-dependent intranets. Others know about web standards, but work at companies that force them to create table-based layouts, to author to IE5’s incorrect CSS box model, and so on.
Microsoft cannot abandon these web builders, nor can it hold itself blameless for their platform- rather than standards-based approach. After all, during the bad old days, companies like Microsoft and Netscape helped create ill-informed web developers, by encouraging IT folk to develop for their proprietary web “platforms.” There may even be divisions of Microsoft that still sell this snake oil, despite the company’s general embrace of web standards.
And professional developers who don’t know better are but a loogie in the bucket of unenlightened web creators. There are millions of small business owners, school teachers, pastors, coaches, and so on who create websites every day, armed with crappy software and little else. Such sites are rarely models of great design, good writing, or passable usability, and they are almost never marked up in valid XHTML or authored to anything resembling Bert and Håkon’s CSS specifications.
This unenlightened customer group either doesn’t test at all, or “tests” only in the version of IE that came with their computer. You and I may not care about these millions of lumpen web auteurs, although we would love to convert them to standards-based design, but Microsoft, being a corporation and all, can’t dismiss them. To satisfy the unenlightened, Microsoft must ensure that as IE becomes more compliant, it does not “break” the badly authored sites they create. (Break is in quotes where some might hold that a site which displays incorrectly but still functions is not necessarily broken.)
Satisfying both groups is nothing new. Browsers figured out how to do it in 2000—namely by implementing the DOCTYPE switch invented by The Web Standards Project’s Todd Fahrner. But the old trick no longer works—at least not for IE.
Riding two horses with one behind
When IE’s compliance leaped forward with IE7, at least temporarily satisfying Microsoft’s first customer group, the badly authored sites created by the second customer group stopped working correctly, leaving unenlightened developers profoundly peeved.
From the outside, to readers of ALA and other standardistas, the IE7 upgrade smelled like victory, with future triumphs all but certain to follow. But inside Microsoft, apparently, the damage to skrillions of badly authored websites was not considered an acceptable casualty of progress. If Microsoft’s IE team was to stay employed and continue to improve the browser’s standards compliance, a new way would have to be found to protect the work of unenlightened developers.
“We can’t break the web” became the mantra. (I know this because, at a recent conference dinner, I was seated near some Microsoft people who kept saying it.)
Absurd but correct: the opt-in default
The DOCTYPE switch once allowed browser makers to properly support standards-based design while not “breaking” ineptly authored sites. But as The Web Standards Project’s Aaron Gustafson explained in Issue No. 251, the presence of a complete DOCTYPE in the head of an (X)HTML document no longer reliably indicates that the developer knew what she was doing and the page should be rendered in standards mode.
By contrast, zillions of people who don’t know any better do tailor sites to the quirks of IE6. That’s why an improved IE7 “broke” old sites. And it’s why, in crafting a new switch, Microsoft must build its default to protect unenlightened developers. This is how they arrived at the seeming absurdity that IE42 will act like IE7 unless a knowledgeable developer deliberately overrides this default behavior by inserting an optional
meta element into the head of the document (or using an HTTP header and leaving their markup pure).
It has to work that way or it doesn’t work at all—as absurd as it sounds and as nuts as it drives Jeremy Keith and many other sensible web designers. (And as nuts as it drove me for the first seven hours after I heard of it.)
If IE8 acts like IE8 by default, then IE8 might break group two’s websites (and not just break them in quotes: we’re talking about scripting, here). Breaking millions of sites is unacceptable to Microsoft’s brass and to the creators of those websites. It’s to prevent that breakage that Microsoft’s browser developers came up with the new switch. To do its job, the new switch must work the same way the DOCTYPE switch originally worked: namely, it is activated when knowledgeable developers opt in; otherwise it is off by default.
With DOCTYPE switching, “off by default” means “in (non-standards) quirks mode.” With version targeting it means “the same way IE7 rendered this content.” The behavior is the same in both cases: if you want improved rendering, you opt in.
Is this switch really necessary?
You may question the idea that the new switch, which would have eased the transition to IE7, will be needed in future versions of IE, since the tough part of the transition to greater standards compliance has already taken place. And this is true where CSS is concerned. For the most part, any site that renders acceptably in IE7 ought not to “break” in IE8.
Of course, one can never be sure with hypotheticals; even if scripting were not an issue, it’s possible that any new version of IE would break something, and that version targeting is a timelessly swell idea on the grounds that it offers a mechanism to prevent breakage for any reason. It’s nevertheless true that, for many CSS-oriented web designers, the case for creating a new switch now seems less urgent than it would have been just prior to the introduction of IE7.
Still, even if version targeting were merely the tribute Microsoft’s browser engineers had to pay their corporate overlords to retain permission to keep improving IE’s standards compliance, what would be the harm? The
meta element is valid, and its use is optional. The HTTP header is easy, and leaves your markup pure.
Questions? You, in the front row:
“Once again, we’re being asked to make special accommodations for Microsoft. Why can’t this annoying company get their browser’s standards compliance to be as accurate as Firefox’s? Why do they put the onus on developers?”
One accommodates Microsoft as one’s ancestors accommodated Imperial Rome. As a wiser man than me said, “Render unto Caesar.”
But while the opt-in protects old-fashioned coders from a major change in the scripting environment, it also offers unique benefits to even the most die-hard standardista.
The onus is no longer on the developer
What’s really new is that by opting out of Microsoft’s version targeting (by not including the optional HTTP header or
meta element), you get to skip testing in future versions of IE. If your site works in IE7 today, it will work in IE47, or so Microsoft has promised. It will work in IE47 even if IE47 is a bleeding disaster from a standards point of view. So long as IE47 properly supports version targeting’s default setting, your site will work just as well in IE47 as it does in IE7.
That is the very definition of forward compatibility, although it is not the route I expected us to take when I coined the phrase “forward compatibility” while formulating the benefits of standards-based design.
Flip to the other side of the coin and here’s what you see:
The system is opt-in. It’s our choice whether or not to include the optional
meta element (or HTTP header) that triggers version targeting. Therefore, in fact, developers are no longer being asked to accommodate Microsoft—at least not beyond the known blemishes of IE7. Instead, Microsoft has committed to accommodating us.
This is a huge change and a benefit to anyone who has struggled to get their standards-based work to look or behave right in IE. Today’s IE is light years more compliant than the old versions we struggled with. And Microsoft has promised to improve compliance forever. If we opt in, we can expect the same level of scripting support in IE that we get from the browsers we love. Improved, predictable standards support in all browsers. Isn’t that what we all want?
At the same time, Microsoft is providing a mechanism whereby no designer or developer will ever again be surprised by a new IE version that behaves unexpectedly. If I permanently opt out of version targeting, I will never have to learn another IE quirk or workaround. That’s probably not what my agency or I would do, but it’s a viable option. (And if enough of us did it, Internet Explorer would gradually lose market share, which would make some people happy.)
If I opt in on my staging server, I can test old sites in new IE versions by adding a
meta element. If the old sites don’t work, I remove the element—and to my client, the old site works great in a new browser.
Designers and developers should be popping corks, hugging each other, and weeping with joy. IE no longer sucks. Cross-browser unobtrusive scripting, with no extra work for IE (save the “work” of including a
meta element or
HTTP header), will soon be a reality. No version of IE will ever again surprise us with unexpected displays or behavior.
The blue pill
Version targeting is a mind-bender. It shakes our browser-agnostic faith. Its default behavior, although beneficial to skilled and unskilled developers alike, runs counter to our expectations, and seems wrong. And it presents at least one Sphinxian riddle: namely, how can IE8 pass Acid 2 if IE8 behaves as IE7 by default? You can spend weeks on that one and not come up with a logical answer. Call me Lewis Carroll, but I’m okay with it.
Aaron Gustafson contributed to this article.