Martian headsets for Earth people: How to fix Internet Explorer 8

by Sander Marechal

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 IEs 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:

  1. /*\*//*/
  2. E {property: value;}
  3. /**/

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:

  1. Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; YPC 3.0.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)

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:

  1. <!--[if IE6]><p>Some IE6 only code</p><![endif]-->

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: This article on Digg

Creative Commons Attribution-ShareAlike

Comments

#1 NoCaDrummer

Why not make the next IE to be "Standards Compliant" by default, with a button to "emulate IE7 [or any other IE, for that matter] on this page". It could be much like the "exceptions" pages that we might have our browser block, not download pictures from, etc. If you go to a page which is rendered incorrectly because the poor SOB who had to write the code wrote it to check for IE and it nudges things differently, then the "emulate" button re-renders it in IE7 mode, and saves the URL so that the next time it's visited, it gets rendered "correctly". Keep the button on the toolbar so that IF the page is changed in the future (to render right with standards-compliant browsers), it can be easily taken off the self-kept list and rendered correctly with IE8 or any other browser.

THAT seems like the logical way to get the idealists with 99% right in principle and the pragmatists 99% right in practice. Keep it simple, keep it true.

Remember, you heard it from me first. Can I patent that idea? [NOT!]

#2 Anonymous Coward

Excellent post, and I hope Microsoft tries it. I'd be grateful if you'd modify your incorrect use of apostrophes, though.

NoCaDrummer also has an excellent point. Could do worse than including that fix as well.

#3 Sander Marechal (http://www.jejik.com)

Why not make the next IE to be "Standards Compliant" by default, with a button to "emulate IE7 [or any other IE, for that matter] on this page".


It's a valid solution and it would certainly work for you and me, but it's probably too complicated for most Internet Explorer users. They don't even know what standards compliance is, or what the differences between IE7 and IE8 are. And if you need that button on more than half the websites you visit then it's still not very user friendly. But it is possible to implement such a button on top of my suggestions as a way to fix the last 0.1% of websites that do not work.

I'd be grateful if you'd modify your incorrect use of apostrophes, though.


Sure. And I'd be grateful if you can point them out to me. If you hadn't noticed, English is not my native language :-)

#4 Anonymous Coward v2.0

The incorrect apostrophes noted by the other Anonymous are in the possessive and contractive forms of the pronoun "it." "It's" is the contraction of "it" and "is", while "its" is the possessive form of "it." For example:

"have it's cake and eat it too" would become "have its cake and eat it too" while "it's not a silver bullet" is correct.

#5 Sander Marechal (http://www.jejik.com)

Always those "it's" that get me :-) I think I fixed them all. Thanks.

#6 geoff_f

In a similar vein to the apostrophes mentioned beforehand, in the context of "who's javascript", "who's" is not a contraction of "who is", but the possessive case of "who"; it should be "whose".

#7 Jezuch

"Browser snuffing" - I love that! ;)

#8 Sander Marechal (http://www.jejik.com)

Thank you. It should all be fixed now. The 's always confuses me because Dutch rules state pretty much the opposite of English rules. In Dutch you use 's to denote possession.

#9 Allochtoon

In werkelijkheid is het niet andersom in engels, omdat in engels gebruiken mensen ook 's voor bezittelijk -- uitgezonderd bezittelijke voornaamworden. Bijvoorbeeld: "Tom's" of "mother's", maar "his" "hers" of "its". En in nederlands zal je niet "on's huis" schrijven.

#10 Anonymous Coward

That's the case in English as well, at least generally speaking. English just has several odd exceptions to its different rules.

#11 Alan Gresley (http://css-class.com)

@Sander

Internet Explorer 8 should have no problem with CSS hacks.


Actually IE8 has taken a step backwards regarding CSS hacks. I have this unfinished article titled The Hadron Zoo of hacks for IE.

I believe that instead of the IE team making IE8 a CSS2.1 standard compliant browsers from the specs they just emulated other browsers behaviors. The problem with this approach is that no browser is consistent (not even the betas) with CSS2.1 support.

#12 Sander Marechal (http://www.jejik.com)

Wow, that's a nasty collection of CSS hacks you have collected there Alan. You would have though that the IE8 team could have implemented a proper CSS parser by now. Or at least a parser that can properly handle C-style /* */ comments in all their escaped forms. After all, C compilers have been correctly parsing those kind of comments for over 35 years now. And a number of C compilers are in the public domain or under BSD-style licenses, allowing the IE8 team to simply reuse that code.

But I don't think it matters much for the premise of my article. The problem with CSS hacks that I outlined are hack targeted at IE7 and below that are still parsed by IE8. Looking over your list I don't see any hacks that work on IE8 and that are currently used widely on the web to target IE7 or below.

Perhaps you have excluded such hacks from your article though. As you say in your article, your hacks are about targeting IE7 without targeting IE8 as well. If you know of any CSS hacks that are used widely and that inadvertently target IE8 then I'd gladly update my article and include them in the list of things the IE8 team should fix.

My primary concern in passing off IE8 as a standards compliant browser is successfully evading CSS hacks that are currently used on more than a negligible number of websites. We can start bashing the IE8 team for all the new hacks and problems after they manage to render at least the 99.9% majority of websites correctly :-)

#13 Anonymous Coward

They should just change the IE8 useragent to firefox :) Just like they did back in the day with mozilla (ever wonder why IE has mozilla in its useragent?)

#14 Anonymous Coward

To sum it up, IE8 needs to pretend to be firefox and pretend not to be related to IE6 & 7 and all will be well :)

#15 NoCaDrummer

Besides the "emulate IE7" button, a Preference setting could choose its "normal" interpretation. That would be useful for those who visit non-standards compliant sites most often. But it would have to be set as "standards-compliant" as default. One-by-one, web pages should be moving toward compliant code, not away from it.
Still, I think that having the Help Guide mention what the button was for would be a huge benefit. "Q: The web page displays incorrectly, what do I do?" "A: First try toggling the [whatever color] 'standards' button located next to the location bar."
Clicking the button (whatever mode it was in) would re-draw the screen, using either the IE7 mode or "standards" mode. Even relatively stupid users should know to check the Help if things are really f----d up. Okay maybe not. But then those are the ones who use the CD drive as a cup holder, and probably should be given Norplant (or equivalent for one's gender).

#16 Sander Marechal (http://www.jejik.com)

Still, I think that having the Help Guide mention what the button was for would be a huge benefit. "Q: The web page displays incorrectly, what do I do?" "A: First try toggling the [whatever color] 'standards' button located next to the location bar."


They could do even better. IE8 could detect the use of open-ended conditional comments or attempts to access document.all and in response display a bar across the top, similar to the bar you see in Firefox when it blocks a popup. That bar could warn that the page appears to be optimized for older versions of Internet Explorer and show the "switch to IE7 mode" button, along with an option to remember that setting for this domain.

#17 Alan Gresley (http://css-class.com)

Hi Sanders

If you know of any CSS hacks that are used widely and that inadvertently target IE8 then I'd gladly update my article and include them in the list of things the IE8 team should fix.


I guess you missed it.

<code>
/*\*//*/
E {property: value;}
/**/
</code>


The pass band filter which was designed to target IE/Mac but now also targets IE8 (discovered by Ingo Chao) but this could be simply.

<code>
/*/
E {property: value;}
/**/
</code>


and reformatting these we have

<code>* /*\*//*/+ /**/html E</code>

<code>* /*/+ /**/html E</code>


I can assure that the IE team are aware of these filters etc. have been discovered. The important point is that these CSS constructions are all valid CSS and it' the invalid ones targeting or filtering IE8 that shows the status of the IE8 CSS parser. Not hacks but rather malformed rulesets or declarations that should be dropped.

#18 Sander Marechal (http://www.jejik.com)

Thanks Alan. I've updated the article accordingly.

It certainly looks as if the IE8 team simply picked their old parser and implemented detection and workarounds for the most exploited parsing bugs, instead of simply fixing their parser.

#19 Manfred Staudinger (http://documenta.rudolphina.org/cond-css-demo.xml)

Beyond Conditional Comments - what about a generalisation of CC's? You can target Safari or Firefox and more without Javascript - view a demo with the URL above.

#20 Davin

Like most things, there is what we know and what we should know. If browsers all displayed things to the same standard, the web would be a friendlier place. The problem lies with the fact people don't like change and so MS has patched things along, never really starting from scratch. But I do feel all browsers should cut loses one day and encourage progress. Rather than supporting poor programming and design.
Post a new comment

Registration is not required to post comments, but cookies must be enabled. One of the advantages of registration is that you can edit your comments later on (editing not yet implemented). You can register or login here.




Your e-mail address will not be published, but your website URL will. All links that you post will tagged rel="nofollow" to throw off spammers. You are allowed to use the following XHTML tags in your comment: <em> <strong> <u> <b> <i> <strike> <blockquote> <big> <small> <ul> <ol> <li> <a href=""> <pre> <code> <tt> <br>. Please allow up to 60 second processing time after you post a comment. Our spam filters may take some time.