…web design…

IE8 version targeting…

IE8 continues to stir up debates in web developer communities by the tactics used to “make it work without breaking the web” as Microsoft's policy seems to demand. Having followed the “game” since the beginning early in 2008, I'm not too worried anymore.

update [04.mar.2008]: Looks like the problem is solved – by Microsoft!
Read all about Microsoft's Interoperability Principles and IE8 and rejoice!
It's still bad, but it could have been a lot worse.

update [18.feb.2009]: Not sure if the Compatibility View Improvements to come in IE8 reintroduces the original version targeting problem or just walks in tight circles around it, but those web developers/designers who really, really, want standard compliant rendering in IE8, may as well enforce it.

If, or when, I have to opt-in, I choose “the edge” where we have the following alternatives:
META: <meta http-equiv="X-UA-Compatible" content="IE=edge" />
HTTP header: X-UA-Compatible: IE=edge

what options the “twice revised” version targeting gives us:
Common Name New Compatibility Mode Meta Value compatibility comment
Quirks IE=5 (IE=6) equals IE7 quirks mode more or less (for now).
doctype irrelevant.
IE7 Standards IE=7 equals IE7 broken standard mode.
doctype irrelevant.
IE8 Standards IE=8 equals IE8 standard mode.
doctype irrelevant.
Best possible mode IE=edge (default without meta) always latest IE-version.
doctype is used as mode-switch.

Note that the above table shows my own interpretation of existing documentation pr. 08.mar.2008, and as such there may be errors. IE8rc1 is out now (february 2009), so anyone can do basic testing for themselves.

Note also that “version targeting” is a misnomer, as we can not really target IE-versions – only a limited number of IE-modes. The whole idea is still pretty flawed, but hopefully the number of IE-modes open for targeting won't grow with future IE-versions.

I'll leave my original comments on the initial version targeting proposal in place, since one never knows if/when they may come handy. The following is (more or less) what I wrote on 26.jan.2008:

In case anyone should be completely unaware of what this is all about, there's plenty of information and opinions elsewhere on the web. Avoid being affected by the “slightly less than civilized” language in some posts – and especially in some comments, and you should be able to extract all relevant facts as they are known as of this writing.

As for myself: I got a hint that some form of versioning might be introduced in IE/win one day, as it came up during discussions with members of the IE-team when we prepared the first public version of our On having Layout article – back in 2005. Thus, it didn't come as much of a surprise when I read the Beyond DOCTYPE article on ALA now in January 2008.

The idea of having version targeting looked good to me at first (back then), but after having evaluated the potentially damaging consequenses back and forth for a few days, I changed my mind. Version targeting in the form it was presented back then, and in the form it is presented now, is not a good idea, and may break the web even more than it is already. We on the “hasLayout” team spoke against all forms of versioning back then when we had a chance, and haven't heard anything substantial about the issue since.

MSIE-only problem…

The problem with the presented version target mechanism is that we have to “opt in” – add a meta or alter the page-headers – to get to the standard complient side of IE8, while broken sites can stay broken and get the non-standard rendering they are created for by default. The people behind broken sites won't have to do anything.

Those who have some old sites on the web (or elsewhere), and those who have done bad work or not bothered to upgrade to standards, are let off the hook when IE8 comes out. In theory that's ok with me, but not when their work is presented with a doctype that should only be used by sites built to web standards.

Problems caused by abuse of doctypes documents can't live up to should be the abusers' problem, and be left for them to solve. Such problems should not end up anywhere near those of us who stay as close to evolving web standards as we possibly can and declare a doctype that our documents can live up to at the time of creation.

The doctype gave browser-vendors a trigger for switching to standard compliant mode(s) in browsers, as all browsers have included a doctype switching mechanism that's supposed to separate non-standard and standard based documents for “quirks mode” or “standard mode” rendering. This switch works just fine when doctype isn't abused and added to sub-standard documents simply to act as a switch.

Properly declared doctype and the doctype switch should be enough even for IE/win, but the real problem is of course that we get “anything but standard” in IE6, and “not really standard yet” in IE7, so the “doctype switch” clearly doesn't work as prescribed in Microsoft browsers. It never has, and Microsoft now seems to have decided that it never will.

IE/win' less than optimal use of the “doctype switch” from the start, is what's causing the problems now. This despite the fact that Microsoft launched the first browser that made use of the doctype as a standard mode switch – in IE5/Mac, and later introduced the switch in IE6. Microsoft missed the oportunity to fix today's problems, back in 2001 (see browser timeline).

Other browser-vendors also introduced the doctype switch, somewhat reluctantly, a little later, and optimized their respective standard compliant and quirks mode rendering the best they could from there on, and have managed to iron out most problems with this switching-strategy without introducing new ones. Thus, only Microsoft seems to have ignored web standard compliance for so long that their browser's weaknesses and breaches with same standards have become a lasting “backward compatibility” problem. Now they're turning it into a “forward compatibility” problem.

wrong default…

If Microsoft had introduced a “backward compatibility switch”, then few, if any, forward thinking web developer would have complained – I most certainly wouldn't. Any site that makes too heavy use of IE/win' bugs and flaws to survive in a standard compliant browser like IE8 is supposed to become, could then simply “opt out” of standard-compliance and trigger an older and (for them) safer rendering mode in any and all future IE/win versions.

However, Microsoft want us to add a trigger for a “forward compatibility switch” just to make their future browser-versions act properly. We have to “opt in” for standard-compliant rendering, and that approach is simply wrong no matter how one twists and turns it. Web standards are under constant development, while old IE/win bugs and broken sites with doctypes they can't live up to, belong in the past and should “opt out” of the race if their owners don't like progress.

Now, bear with me for a moment, as I really don't think it is too much to ask for when I want all broken sites with doctypes to be updated with a trigger for a “backward compatibility switch” in IE8 and future versions, and be done with these compatibility problems that haunts IE/win once and for all. Checking and updating a few million sites with a combined number of pages into the trillions, shouldn't take all that many days and/or weeks. After all: most old and new sites/pages don't have a doctype to trigger mode switching on, and are therefore not in need of any updates. Thus, it is not like the task is an impossible one where all sites in existence have to be updated to avoid being broken by an improved IE/win.

Intranet sites, which may abuse doctypes more than actual web sites do, can probably be updated automatically without any real delay or cost. If not, then it isn't like they don't have the option, and power, to prevent future IE/win upgrades – forever if they want to and can keep their broken intranet going.

The result of adding such a trigger for “backward compatibility” to the existing sites that need one, would be tremendous, as neither the site-owners nor Microsoft would have to go through this more than once, and most of the update-process could be automated. Even updating a few hundred thousand static documents automatically pr. hour, should not pose any real problems for anyone who has that many broken documents on or off line.

Updating broken sites certainly sounds better than having to update and then test every decent standard based site in new versions of IE/win as they arrive from now on and into the very distant future, just to be able to expand our use of web standards in a standard-compliant IE/win – the way it works by default in all other major browsers.

Trusting the “edge” quality in IE/win is really not an option in my opinion, at least not until the next few IE/win versions have proven that Microsoft can deliver a reasonable product-quality, and that may take more than a few years to establish.

short-term solution…

The presented “opt in” may solve Microsoft's problems right now, and it clearly isn't meant to solve problems for anyone else – now or in the future. Thus, the “opt in” will probably be part of IE8 and future versions, and keep on creating problems for as long as Microsoft launches new browser versions.

I'll wait to see what state of standard-compliance IE8 is in, before making any decisions about if and/or when to “opt in” for anything. IE8 has to be pretty darn good, and at least on level with the other major browser at the time of launch, for me to seriously concider adding anything for it. Time between IE/win versions is also too long to accept anything but near perfect standard-compliance at the arrival of each one from now on.

Microsoft is actually promising that no site that works in previous version(s) will break in IE8, since it'll default to IE7 rendering in “standard mode” and IE6 rendering in “quirks mode” when we do nothing. Not that I'm trusting Microsoft's promises more than I like the presented version targeting – not one bit.

I won't mind being proven wrong on this point though, because if Microsoft keep their promise, we should be able to relax and set the whole version targeting issue aside until we can check performance of future IE/win versions in depth. I have no problem with that, but I'm kind of slow and easily get hung up in buggy details, so it may take a while.

I don't know, but I may end up using a standard trigger IE/win so far hasn't been prepared for – whenever I can. Don't think that approach should lock down IE8' version targeting mechanism in the wrong mode, but I also not sure if IE/win will ever have a working mode for it. Time will tell.

For now I'll keep exploring potentially damaging consequenses of the presented version targeting, blacklisting and so on, as I am convinced such versioning is not a good idea and that it'll do more harm than good if implemented in IE8.

sincerely  georg; sign

Hageland 26.jan.2008
08.mar.2008 - 1st reversal: opt-out.
18.feb.2009 - 2nd reversal: blacklisting.
last rev: 18.feb.2009


Version targeting in the form it was presented back then, and in the form it is presented now, is not a good idea, and may break the web even more than it is already.
— Georg

IE/win' less than optimal use of the “doctype switch” from the start, is what's causing the problems now.
— Georg

I'll wait to see what state of standard-compliance IE8 is in, before making any decisions about if and/or when to “opt in” for anything.
— Georg

More MSIE versioning issues – and something extra:

More rejoice and follow-ups:

compatibility view in IE8 (AKA: blacklisting):

…2008 - 2009