Andy Clarke discusses possible solutions to the IE6 problem, and then highlights his own: create one Universal Internet Explorer 6 CSS file that will give any page a nice-but-basic typography and margins, but no layout or grid at all.

Interesting idea. We'll have to see what clients want (or whether they'll notice), but it sounds like an excellent intermediate solution between "don't bother with IE6" and "make IE6's rendering pixel-perfect".

Tim Cameron Ryan has written a script to work around the differences between an IE Text Range and a W3C Range. I applaud his courage; I once considered doing this but the incompatibilities were terrible and I decided I needed a little more practice; practice I never got because my career started moving away from production coding.

John Allsopp interviews Pete LePage; among other things about the IE8 compatibility modes.

EmulateIE7 is not truly equivalent to testing in IE7, but it’s pretty close. When building Internet Explorer 8, we were able to version the layout and rendering engine, but it was impractical to version the entire end-to-end system; for example the networking stack, parser, security fixes, HiRes layout, JavaScript engine, some DOM APIs, etc… In practice, though, we've found that IE8 Compatibility View works extremely well for most sites. For most cases, this should be enough, and for final verification, we provide the VPC images that you can download and test with a clean version of Internet Explorer 7.

Although this is probably not what web developers want to hear, I'd say let's give them a chance — until really, really serious incompatibilities between IE7 and IE8-as-IE7 are discovered.

Once again rumours are flying; Will IE8 Be The Last IE? I'll believe it when I hear it from the horse's mouth.

This article suggests that MS is looking into using the WebKit engine, OR that the Gazelle browser may replace IE in the future.

Unfortunately the article misses the obvious: the Gazelle paper talks about architecture; and not about rendering engines. Therefore an as-yet hypothetical Gazelle might be combined with either Trident or WebKit. In other words, both rumours might be true simultaneously.

Or none of them could be true. We'll see. Let's get a good IE8 out on the market first, and then worry about its successor.

Dan Cederholm shares a simple but efficient trick for dealing with IE6 through conditional comments. I had a 'why didn't I think of this' moment when I read it. It's that simple. (But of course, thinking of really simple solutions is the most difficult job there is.)

Isolani points out an IE Blog article about the rendering mode switch that I missed. Turns out Microsoft is going to blacklist sites where many IE8 users switch back to IE7 mode: apparently these sites need this mode, so IE8 is going to automatically engage it.

Isolani proceeds to critcise the idea, and he has a point when he says:

What is even worse is that sites are blacklisted by top-level domain. As the IE8 blog post describes:

The data we collect from IE8 beta users is the top level domain of the website and whether the user chose Compatibility View while visiting that site.

This is insidious; organisations running multiple sites on subdomains (like Yahoo, AOL, CNN, Blogger, WordPress, Wikipedia, Ning) are exposed to a new risk: a problem with one single subdomain is sufficient to black-list all their websites into an IE7 Compatibility Mode.

This could indeed be a problem. Although I see the IE team’ reasons for making this move, huge top-level domains could indeed be hit hard.

We should not actively block IE 6 users or completely disregard what happens when an IE 6 user comes along. What we should do is spend less and less time working around IE 6 bugs unless they seriously affect functionality or accessibility – only fix the showstoppers.

As long as we make sure to use progressive enhancement, content and base functionality will still be there, like for all other antiquated browsers.

Standards are a great goal, of course, but before you become a standards fanatic you have to understand that due to the failings of human beings, standards are sometimes misinterpreted, sometimes confusing and even ambiguous.

The precise problem here is that you're pretending that there's one standard, but since nobody has a way to test against the standard, it's not a real standard: it's a platonic ideal and a set of misinterpretations [...]

Spolsky also says almost every site he visited in IE8 is broken. This is likely to be true, but it's not entirely fair, since this is the very first beta of the new browser, and historically Microsoft's very first version of any browser have always been quite bad. I, for one, will only make such comparisons once beta 2 has been released.

So you see, we have a terrific example here of a gigantic rift between two camps.

The web standards camp seems kind of Trotskyist. You'd think they're the left wing, but if you happened to make a website that claims to conform to web standards but doesn't, the idealists turn into Joe Arpaio, America's Toughest Sheriff. "YOU MADE A MISTAKE AND YOUR WEBSITE SHOULD BREAK. I don't care if 80% of your websites stop working. I'll put you all in jail, where you will wear pink pajamas and eat 15 cent sandwiches and work on a chain gang. And I don't care if the whole county is in jail. The law is the law."

On the other hand, we have the pragmatic, touchy feely, warm and fuzzy engineering types. "Can't we just default to IE7 mode? One line of code … Zip! Solved!"

Secretly? Here's what I think is going to happen. The IE8 team going to tell everyone that IE8 will use web standards by default, and run a nice long beta during which they beg people to test their pages with IE8 and get them to work. And when they get closer to shipping, and only 32% of the web pages in the world render properly, they'll say, "look guys, we're really sorry, we really wanted IE8 standards mode to be the default, but we can't ship a browser that doesn't work," and they'll revert to the pragmatic decision. Or maybe they won't, because the pragmatists at Microsoft have been out of power for a long time. In which case, IE is going to lose a lot of market share, which would please the idealists to no end, and probably won't decrease Dean Hachamovitch's big year-end bonus by one cent.

He's right in his thumbnail sketch of the web standards camp; we LOVE the big stick the IE team is handing us on a silver platter, and frankly I'm not sure if having that stick is good for us in the long run. There are too many web standard fascists already.

As to the IE team changing the default again, who knows ... ? If they do I, for one, will fully understand that decision.

Pity the Internet Explorer developers working their arses off to add great standards support to their browser, only for that work to manifest itself on but a tiny proportion of web sites. Bit of thankless job, if you ask me, but I hope they stick at it.

Exactly! It's commonly forgotten that the versioning switch was introduced because the IE team wants web standards.

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.

Exactly! True, doctypes are also used to define the flavour of (X)HTML you're using, but that means that the IE versioning switch is better than doctype switching, since it's only meant for determining a browser version to run in.

The more I think about it, the more I feel that standards-aware web developers behave like little children. They want what they want, and they want it now!

Jeremy continues the argument against the versioning switch. Although he agrees that versioning switching by itself will be a useful tool, he still disagrees with the default.

This strategy is doomed to failure. Standards-aware developers, by their very nature, will object to adding a line of unnecessary markup to their documents just to get one single browser to behave as it should by default.

My question is: why do they object? What's the problem with adding a single line of code to placate IE? Right now we're writing whole style sheets with that goal in mind. (Besides, not all standards-aware web developers object.)

Bruce points out the accessibility problems the versioning switch will cause: large amounts of the Web will be stuck in IE7 mode.

Although that's undeniably true, the solution is obvious: if accessibility is really an issue, switch to IE8 mode. Yeah, I know there are plenty of people who don't know how to do that or what to do once they arrive there, but how is that situation worse than today's?

Even today, you need a serious web developer in order to make your site really accessible. Serious web developers know about the switch and can estimate its accessibility impact, once enough research has been done.

Contrarily, unaware developers won't be aware of the switch, but they won't be aware of the latest and greatest in accessibility, either, so their not knowing about the switch or the difference between IE7 and IE8 mode pales into insignificance.

All in all I'm not convinced that accessibility will suffer. Even if IE8 had been a normal browser with a normally upgraded engine, we'd still have to cater to IE7 and its accessibility problems for the foreseeable future.

David Storey disagrees with the versioning switch. In fact, he attributes it to a alleged Microsoft "Divide and Conquer" strategy; something I cannot agree with.

While I understand Chris Wilson's position on "Don't break the Web", and very much understand that this is an incredibly hard nut to crack (I work on similar issues every day), it feels like this proposal is more "break the web for others". There must be a better solution.

I'd like some more information on this. Exactly how will this break the Web for non-IE browsers? I've heard this argument now and then, but have never yet gotten a good reply.

Eric offers an older example from the time he still worked at Netscape. Webmasters simply weren't interested in the "you're doing it wrong so that's why your site breaks in our new version" argument—and they're right, from their point of view.

Microsoft had the choices of either having some opt-in to improved standards support, or not improving standards at all. An opt-out wasn’t an option, because live content isn’t using that opt-out. Now, every angry and disappointed web developer out there, if you look at it that way, which one would you prefer? Standards with an opt-in or no standards at all?

I think a lot of people are discounting the fact that version targeting is absolutely nothing new in the standards world, let alone the web development world. Conditional comments, CSS hacks, and the DOCTYPE switch itself are all examples of version targeting.

That's certainly something I feel people are generally disregarding. The difference between the doctype switch (and CSS hacks) on the one hand, and the new version switch on the other, is, of course, that the first is widely known and the second one is new. Conservatism?

[The other browsers] don't need a meta tag in addition to a proper doctype, why would IE?

IE has a specific problem the other browsers don't have: Intranets maintained by people who are not (and maybe do not want to become) web developers, let alone standards-aware web developers.

And what's to prevent us from automatically adding meta tags anyway?

Nobody's going to prevent us, but why would you (unless you know what you're doing and WANT IE8 mode)? Doctypes were also necessary to create valid (X)HTML; the meta tag does not have such an extra function. Therefore it will only be added because web developers want to switch IE to a certain mode.

The argument about expected rendering behavior is even more absurd. No serious developer still believes that what IE renders is actually correct.

This is the key point where I feel the No camp is making a serious mistake.

We automatically define "web developers" as "standards-aware web developers". Unfortunately there are plenty of other web developers around. Feel free to denounce them as incompetent, but do not deny that they're an important factor, especially for Microsoft. They are the ones who maintain Intranets created specifically for IE, and any implementation of the standards in IE must take their needs into account, or fail miserably for business reasons.

Dean Edwards disagrees with the versioning switch, and also objects to using WaSP as a front. That last criticism rings true: WaSP as a whole wasn't involved in this decision, and it shouldn't be pretended that it was.

Ian Hickson disagrees with the versioning switch. I can't resist the temptation to reply to some of his arguments.

If Web authors actually use this feature, and if IE doesn't keep losing market share, then eventually this will cause serious problems for IE's competitors — instead of just having to contend with reverse-engineering IE's quirks mode and making the specs compatible with IE's standards mode, the other browser vendors are going to have to reverse engineer every major IE browser version, and end up implementing these same bug modes themselves. It might actually be quite an effective way of dramatically increasing the costs of entering or competing in the browser market. (This is what we call "anti-competitive", or "evil".)

I believe Ian paints the current situation too black. True, other browsers will have to take some IE bugs into account when updating their rendering. However, one of the points of the versioning switch is to allow IE to become more standards compliant, so the difference between IE's higher rendering modes and the other browsers would become smaller and smaller as time progresses—which means less and less implementations of IE bugs are necessary.

An ideal situation, true, but not an impossible one.

It will also increase the complexity of authoring by an order of magnitude. Big sites will become locked in to particular IE version numbers, unable to upgrade their content for fear of it breaking.

Unless they decide to redo their sites and hire competent web developers, who'll switch to IE's highest feasible mode. OK, that won't happen everywhere, but in general those sites that won't be updated to a higher IE mode won't be updated today, either, so the situation will not get worse.

Besides, this is the other point of the versioning switch: if you don't want to update, you don't need to. Eventually this will go for Intranet sites more than for Internet, where the existence of other browsers will have a mitigating effect.

Imagine in 18 years — only twice the current lifetime of the Web! — designers will not have to learn just HTML, they'll have to learn 4, 5, maybe 10 different versions of HTML, DOM, CSS, and JS, just to be able to maintain the various different pages that people have written, as they move from job to job.

Or they could decide to upgrade to the highest feasible IE version. In fact, I feel that the situation Ian sketches could increase the standard-awareness of web developers.

Web developers will have to know about several IE modes; Ian's right about that.

Therefore they have to study web standards as well as the various modes, since without knowledge of web standards the modes are incomprehensible.

Once they gain enough insight in web standards, they'll want to work with the highest feasible IE mode, and will switch the sites they maintain to that mode.

The alternative is that they don't want to learn anything and will stay locked in IE7 mode permanently. That would be a pity, but again we're not worse off than we are today. Today, plenty of web developers don't want to learn the standards, either.

Microsoft is in a really tough position. They have really been trying to listen to web developers clamoring for better standards support. They are also listening to their partners, big corporations with thousands of Internet and intranet pages that would cost them millions to upgrade. Microsoft got slapped when IE7 broke some pages by fixing layout bugs; they couldn't afford to repeat that mistake. Whether we like to admit it or not, there are tons of web sites that are designed to work specifically for IE6. They were written at a time when IE had over 95% market share and haven't been updated since.

There literally is no good move for Microsoft to make in this vein. Either they do nothing and don't break the Web but garner the ire of web developers everywhere, or they pacify web developers by forcing standards on everyone and break tons of web sites and web applications. This is the literal rock and hard place scenario. Microsoft is trying to satisfy both conditions and I honestly feel that this is a huge step forward for IE.

Andy Budd sees the point of the versioning switch, but disagrees with the default behaviour. Fortunately he offers actual arguments:

Clueless developers won't know about this behaviour so every new site they build will automatically be rendered as IE7. Clued-up developers will use this as an excuse to freeze support for IE and turn their attentions to better browsers. Users will see less benefit from upgrading and will be more likely to turn to other browsers.

Clueless developers: correct; that's the point of the default behaviour.

Clued-up developers: this is an interesting scenario that I hadn't thought of yet. It would lead to massive IE7-only style sheets, but that's kind of OK, I suppose.

Users: I'm afraid this is a common misconception. Users don't care what browser they're using.

John disagrees strongly with the versioning switch. He raises a few technical points:

Cross-window scripting. What if one window uses one version mode and another one another? A very valid point.

Security issues. I don't know anything about security, so I really can't judge.

Unfortunately he, too, is making insubstantial claims:

The fundamental issue is that Safari, Firefox, and Opera will all be harmed by attempting to implement this.

I'd love someone to explain this to me. What possible harm can a <meta> tag that they're going to ignore anyway do to Safari, Firefox, and Opera? I suspect an underlying philosophical issue, but I'd like to get it into the open, too. What, besides "it's Microsoft so it must be Evil", is the problem?

Isofarro disagrees strongly with the versioning switch. So strongly, in fact that I'm wondering if he isn't overshooting his target.

Standards compliant pages must always carry a Microsoft passports that identify the holder as a standards compliant page. Sounds like a ghetto to me.

That's what we are being asked to do. We're segregated from the rest of the Web, and forced to carry identity documents that prove we are standards compliant, and earn the dignity to be rendered in a standards compatible way.

Just comparing something you disagree with to something most people feel negative about is too easy—especially when the comparison makes no sense at all. I call this playing for effect, and not serious debate.

Jeremy might agree with the versioning switch, if it weren't for the default behaviour.

Personally I feel that this default behaviour is the whole point of the switch, and besides I wonder whether the situation will become much worse with the versioning switch in place. It may not become better, but I don't see how it will get worse.

Chris Wilson talks about the problems the new versioning switch has to solve. Basically, IE6 was broken, but when IE7 was released and solved a lot of CSS bugs, everybody (except for a few standardistas) still expected it to work exactly as IE6.

Of course, it didn't work that way. Sites optimised for IE6 broke in IE7. That was a major problem for Microsoft, and it's the reason they've added the versioning switch to IE8.

Eric discusses his initial and later reaction to the new IE versioning switch. I agree on the basics: when I first heard of it I wondered if it was such a good idea, but on thinking it over I realised this is probably the best way of handling multiple browser versions now and in the future.

Alex talks about the upcoming IE release, and points out the cause of Microsoft's tight-lippedness (is that a word?): We have harshly (and rightly) rebuked MS in the past, and they don't want to make any false promises again. The easiest and safest way to do that is not making any promises at all. That's what's happening right now.

Alex also wonders about priorities for new browser releases, and he places innovation above standard support; that is, if a browser vendor has a great innovative idea, it shouldn't be forced to go through interminable W3C procedures before being allowed to implement it.

One can agree or disagree with Alex's thesis (I tend to agree), but the really important point is that the standardisation process has become kind of stuck. True, W3C has been mending its ways for the past year or so, but it's still going too slow.

And we all know what happens when there aren't any standards: browser vendors invent their own. Nowadays we can at least hope they'll pay attention to each other's efforts, but the essential problem is the same that plagued us during the Browser Wars.

Nonetheless, this situation has advantages as well as disadvantages. The most obvious advantage is a new wave of innovation, and that's always a good idea.

Will W3C and the web standards movement be cast in the role of opposing innovation in the name of the standards? That would be bad.

I feel that we're on a crossroad now. Standards support, though still important, isn't the be-all-end-all of everything Web any more. We've basicaly won the standards war—browser vendors now pay attention to us. Nonetheless, winning the war might have brought us a whole new set of problems, problems that are mostly centred on W3C being (or having been) so slow.

Which road do we choose? Strict adherence to the standards in all respects—which brings along a certain slowness; or a more innovation-driven approach—which may lead to proprietary extensions (in the sense that they aren't in the specs; but not necessarily in the sense that they differ from browser to browser).

James Edwards makes the remarkable discovery that IE doesn't support the DOM with complete correctness; even if we forgive it for not implementing part of it.

Maintaining a major set of compatibility tables over the past seven has already taught me the same. James adds a few interesting notes, for instance about a second argument to the getAttribute() method, which leads him to conclude that Microsoft hasn't even implemented its proprietary stuff correctly.

Figuring out exact levels of DOM Compatibility is SUCH fun, and I'm glad somebody else is feeling the strain, too. BTW: except for me, James is just about the single person on earth who's going through the major hassle of creating compatibility tables, so I'm glad he's coming to the same conclusions as I have. Misery loves company.

Alex Russell is not happy with Microsoft´s lack of communication about IE progress. Although I´m not nearly as pessimistic as Alex, I agree that some sort of official communication would be nice. It would lay web developers´ fears to rest.

This article contains the details that Chris was willing to give on the upcoming IE8. (In fact, this version number is news to me, too; could easily have been 7.5)

Microsoft is planning to require Web site authors to "opt-in" to standards mode when developing IE 8.0 sites.

This seems to be a sort of super-standards mode (as distinct from the doctype switch implemented back in IE6), and I'm not yet sure if I'm happy about it. I'd like to see a practical example of a situation in which this super-standard mode is desirable.

A test to see if the FTSE 100 company web sites were ready for IE7. Conclusion: 13 weren't, but the damage is slight. Most of these sites were saved by the fact they're not standards compliant, anyway, and IE Quirks Mode has seen little change.

David Flanagan discovers that an event object is passed to event handlers set with the Microsoft proprietary attachEvent() method. This object is not the same as window.event, but contains the same properties.

Everybody kind of assumed that IE only used window.event, but nobody ever seems to have tested it. My book doesn't mention this fact, although I don't think I ever denied the existence of these event objects, either.

I wonder how many more of these curiosities are hidden deep in the browsers' bowels.

It turns out that there are still sites that block IE 7 because (presumably) it isn't IE 6! Once again proof that browser detection is like putting guns in the hands of idiots.

The IE team has added a navigator.userAgent-spoofer that allows users to send IE 6 strings to such sites. Although this is the only possible solution from MS's point of view, it's still a sad comment on the state of the Web.

Chris Wilson gets tired of IE bashing, that continues even now that IE 7 turns out to be a giant step forward. True, IE is still behind the other browsers in some areas, but saying that it's moved forward only '2 %' is just plain nonsense.
'I'd love to have a honest, straightforward, unbiased statement of exactly where we (and other browsers) are – despite the fact that I know we would be behind today.'

Excellent news: IE 7 will be automatically installed via Windows Updates. That means that the time during which we still have to support IE 6 will be dramatically shortened (nonetheless it'll take at least a year before IE 6 has gone entirely; probably more like two years).

Andy Budd wonders about the IE team's drive to get rid of CSS hacks. 'I think the IE dev team are catering to a group of developers who build their sites with IE, rather than the standards in mind.'
Could be, but we'll have to get rid of the hacks anyway.

MS tips for faster DOM Scripting in Explorer. Contains benchmark tests (I thought I was the only one who did that). The tests could use a bit longer loops (1000 iterations instead of the 100 currently used), but all in all the tips have an experimental basis and can serve as a first step towards real benchmarking.