additions...

…web design…

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 

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