Lone Wolves

Updated on 2008-04-10@10:47. Joel Spolsky recently published a very insightful piece called Martian Headsets on his personal blog Joel on Software. It's definitely recommended reading for everyone who deals with standards in some way. The core of his article is about the standards compliance of the upcoming Internet Explorer 8. IE8 presents a problem because, although it is pretty standards compliant, it renders a lot of websites quite badly. The problem is of course not in IE8 but in all the websites that were targeted at IE7, IE6 even lower. As Joel says:

Almost every web site I visited with IE8 is broken in some way. Websites that use a lot of JavaScript are generally completely dead. A lot of pages simply have visual problems: things in the wrong place, popup menus that pop under, mysterious scrollbars in the middle. Some sites have more subtle problems: they look ok but as you go further you find that critical form won't submit or leads to a blank page.

These are not web pages with errors. They are usually websites which were carefully constructed to conform to web standards. But IE 6 and IE 7 didn't really conform to the specs, so these sites have little hacks in them that say, “on Internet Explorer… move this thing 17 pixels to the right to compensate for IE’s bug.”

And IE 8 is IE, but it no longer has the IE 7 bug where it moved that thing 17 pixels left of where it was supposed to be according to web standards. So now code that was written that was completely reasonable no longer works.

A problem with no right answer?

Well, we can't have the majority of websites break in IE8. People would simply not use IE8 and us web designers would still be coding to IE6 and IE7. We want people to move. We want the web to work. So did the IE8 team and they presented a controversial solution that would have IE8 render all pages as if it were IE7 unless the developer specifically told IE that it would render well under IE8.

Personally I think that's a horrible idea. You'd lock the web away in browser-specificness as IE7 level for all eternity. No thank you. Web designers worldwide revolted at the idea and the IE8 team changed its mind. But that still leaves the problem of what to do with all those sites that work badly in IE8.

Joel describes this problem with a pretty apt analogy of the Martian headphone industry, explaining how websites have a many-to-many relationships with web browsers, and how standards can alleviate the problems of such a relationship… if only there was a reference implementation. There isn't, so no matter what the IE8 team finally chooses for IE8 it will be a bad decision, since there is no right decision:

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!”

You see? No right answer.

As usual, the idealists are 100% right in principle and, as usual, the pragmatists are right in practice.

Well, I disagree that it's this black-and-white. There is a third solution possible that allows IE8 to be fully standards compliant and ensures that the vast majority of websites will work just fine. This third option comes from the fact that the vast majority of websites does not really have a many-to-many relationship with browsers. They have a two-to-many relationship. They target buggy Internet Explorer and standard compliant browsers. For IE8 to work well, it has to fall in the group of standard compliant browsers and simply not be detected as a buggy IE that needs special treatment. If this is made possible then IE8 simply gets the standard compliant version of the page which it can render well, and all of a sudden it's only a minority of websites that don't work in IE8 instead of a large amount. After all, Firefox works fine for the vast majority of websites too. This is actually easier to achieve than it sounds.

Defeating browser sniffing

In order for IE8 get the standard compliant version of a page you need to take a look at the various ways that people have used to feed the IE-specific version of a page to Internet Explorer. There are four ways in which you can feed IE something different than the rest of the browsers: CSS hacks, conditional comments, browser sniffing using javascript and UserAgent sniffing. IE8 must pass as a standards compliant browser in all these tests.

CSS hacks

A CSS hack exploits a bug in the parser to trick it into applying some CSS that it shouldn't apply, or to make it skip some part that it should apply. The trouble with CSS hacks has always been “What happend when the next version of Internet Explorer fixes the parsing bug, but not the CSS bug that you were fixing? Your website will break.” This problem is even older than IE7 and people started campaigning against using CSS hacks quite some time ago.

Internet Explorer 8 should have no problem with CSS hacks. The parsing bugs that exploit older IE versions are solved so IE8 will get the standard compliant versions instead.

Update: Alan Gresley points out that there are still a lot of parser bugs in IE8. Fortunately most of the currently employed CSS hacks don't work anymore in IE8. But there is one CSS hack targeted at IE5/Mac that isn't fixed in IE8. This hack will cause IE8 to parse CSS fixes aimed at IE5/Mac and will make the page render badly in IE8. IE5/Win, IE6 and IE7 did not suffer from this so this is a regression bug that the IE8 team should definitely fix before releasing IE8. The CSS hack in question is the IE5/Mac Band Pass Filter:

Thanks Alan for pointing this out to me. For more information see comments #11, #12 and #17 and the page about the IE4/Mac Band Pass Filter.

UserAgent sniffing

Although not recommended, there are still quite a few websites that send different content based on the UserAgent string provided by the browser. The fix is terribly easy of course: change the UserAgent string. A typical Internet Explorere UserAgent looks like this:

All Internet Explorers are currently identified by the "MSIE" part, optionally with their version number. Simply replace "MSIE" with "MS Internet Explorer" or something similar and all current UserAgent sniffers will fail to detect IE8 as an Internet Explorer.

Conditional comments

After people started frowning on CSS hacks and UserAgent sniffing, many people started recommending Conditional Comments as the way to specifically target Internet explorer. Although conditional comments are an Internet Explorer specific extension, they are valid (X)HTML, reasonably safe to use and cause no problems for other browsers. It's a way to wrap a piece of (X)HTML in comment tags. Internet Explorer will parse these tags and the elements inside them (such as a <link> element to include IE-specific CSS code) and all other browsers just see an (X)HTML comment. Example:

These conditional comments can target specific versions if Internet Explorer, or Internet Explorer in general. The only problem for standards compliant IE8 is when people use an unversioned IE target, such as [if IE] or an open-ended conditional such as [if gte IE6], to include CSS or JavaScript that is specifically for IE7 or below.

It would be quite generous of Microsoft to simply say “We don't need conditional comments anymore because IE8 is fully standards compliant” and remove support for them, but that's not very realistic. Besides that, give Microsofts current track record I rather have conditional comments around to fix things that don't work in IE8. Instead the IE8 team should disable open-ended conditional comments. That is: conditional comments that have no upper bound on the version. Open-ended conditional comments are dangerous because they target IE versions that have not been released yet. We have no idea what IE9 or IE10 is going to be like so it's potentially dangerous to target these versions with conditional comments.

So, the solution here is to evalutate open-ended conditional comments (those that do not have an upper bound on their version number) to false. For example, [if IE], [if gte IE6] and [if !IE6] should all evaluate to false, while conditionals with an upper limit, such as [if lte IE7], [if IE8] and [if (gt IE5) & (lt IE12)] should evaluate normally (in case of IE8: false, true, true). This effectively lets IE7 and below work correctly, makes IE8 render the pages correctly and removes the problem for any Internet Explorer after IE8. Developers can still target the current and future versions of IE explicitly, but they can't do it by accident anymore.

There is another up side to this change: For IE9 and beyond it shifts the problem from the web developer community to Microsoft. Suppose there is some bug in IE8 and a web developer uses [if IE8] or [if lte IE8] to fix the problem. When IE9 comes around it will not process that conditional comment. If the IE9 beta renders that page badly then it is because the IE9 team did not fix that IE8 bug. This is a problem Microsoft can control and fix, as opposed to the current IE8 problems where the cause of the problems is the websites and should be fixed by the web designers. In effect it makes web developers always assume that the next version of Internet Explorer fixes the bugs they are trying to work around in the current version.

Browser sniffing using javascript

Of the four methods of targeting Internet Explorer specifically, this one is the hardest to fix. The best way of solving this issue is by only exposing the W3C DOM to pages who want to render in standards compliant mode and to hide the proprietary Internet Explorer DOM. In short, kill off "document.all" and its siblings for all websites that render in standards mode. This should not leave many websites broken since doctype switching started around the same time that people started scripting to the W3C DOM and started applying bugfixes when "document.all" was detected. There should be very few websites that use doctype switching to get into standards mode but whose javascript relies entirely on the proprietary IE DOM.

Conclusion

With the above described fixes (change "MSIE" in the UserAgent string, evaluate open-ended conditional comments to false and hide the IE DOM from pages in standards mode) the Internet Explorer 8 team can have its cake and eat it too. They will be able to default to full standards compliance mode without breaking the vast majority of websites that try to feed a customized page to IE7 and below.

Websites running in quirksmode in IE8 should work just as they do now in IE7 and below, while websites running in standards compliant mode will function pretty much like they function today in Firefox, Opera, Safari and Konqueror. That is: the vast majority of websites will work just fine.

Even better, when IE9 comes along this problem will not repeat itself. That is, if Microsoft and the web developer community start promoting conditional comments instead of hacks to work around Internet Explorer 8 bugs. With conditional comments, any site that renders badly in IE9 do so because the bugs of IE8 were not fixed. It brings the problem back under Microsofts control.

Will the Internet Explorer 8 team implement the above fixes? I don't know. I hope so. It's not a silver bullet. Websites that run in standards mode through their doctype but don't work in Firefox or other standard compliant browsers today probably will still not work with IE8 using these changes. But that is a vast improvement over the large amount of websites that don't work in IE8 standards mode today, or locking the web at an IE7 level of "standards compliance".

Digg this article: