The IE Factor Strikes Back

Logo blatantly stolen from Dean Edwards

I’m currently working my way through a sample chapter Sitepoint‘s DHTML Utopia book – partly to see if I want to buy the book, and partly because I’m trying to get my head around event listeners. I got some way through the chapter, testing my work in Firefox as I went, and it was all going swimmingly.

What happens in Internet Explorer then?, thinks I. Precisely nowt. It was at this point that my colleagues looked around to see what the swearing was all about. From the book:

Naturally, making events work cross-browser is not as easy as just following the DOM standard. Internet Explorer doesn’t implement the DOM Events model very well. Instead, it offers a proprietary and different way to hook up event listeners and gain access to event data.

What’s the point in having a standard if the most popular sodding browser is going to completely ignore it!?

Luckily, the book explains ways around Internet Explorer’s Javascript deficiencies in a calm and friendly manner (e.g. This is inconvenient but not catastrophic; it just means that you have to take different actions for different browsers.). It’s entirely possible that I’ll buy the book, simply because it’ll help dig me out of some big holes.

WARNING IE USERS! STROBE EFFECTS LIKELY!

So, I decided to try applying the lessons learned to one of my own projects. It was all going fine, up until I went to test it in IE. This time, the scripts were working perfectly. No, IE had to find some other way of buggering it up. Now, every time an event was fired, IE decided to re-load all of the background images in the elements effected. Flickerytastic dude! Does this mean I have to put an epilepsy warning up on the page? I navigate away, click ‘back’ and all is fine again.

A bit of googling, asking around on mailing lists, and tearing out of my fast-greying hair reveals that are two ways of fixing the problem:

  1. Get every single one of your visitors using Internet Explorer, AOL, or indeed anything else that uses the IE engine, to alter their Internet Options: Go to Temporary Internet Files, then Settings, then choose Automatic. Realistically, that’s not going to happen is it?
  2. Get your server to add the Cache-control header to the images on your server. Doing this works differently for different servers: ASP.net Resources has the fix for IIS, Dean Edwards has the fix for Apache. If you’re using something else you’ll have to rely on google.

It’s really frustrating that every time I try to do almost anything on the web, Internet Explorer jumps in front of me and holds up an enourmous stop sign. It’s good in a way, in that it forces me to find an acceptable way around the problem. I just wish finding that answer didn’t usually double the time it takes to complete a project. If IE7 really has improved as much as Microsoft say it has, I can’t wait for it to arrive. It’s just a pity that IE5, 5.5 and 6 will continue to linger for as long as they inevitably will.

6 Responses to “The IE Factor Strikes Back”

1. comment_author_url)) { ?> Sara Sara

You’ve found a pretty good book there to help guide you through the process. Do you belong to the SitePoint Community?

I actually found your site through Last.fm, but I belong to SitePoint as well. Been a member for a couple years now, and if you’re not a member currently, be sure to check it out.

Later-

Sara

by the way…nice blog ;)

2. comment_author_url)) { ?> Olly Olly

Thanks :) I am indeed a member, though I don’t visit the forums all that often. Can be a very useful place at times though.

3. comment_author_url)) { ?> Sara Sara

What’s your username over there Olly and I will keep an eye out for you.

I am: ses5909

4. comment_author_url)) { ?> Olly Olly

I’m gnarly.

5. comment_author_url)) { ?> Dean Edwards Dean Edwards

Can you please not call me “Dead Edwards”? It’s spooking me out. ;-)

6. comment_author_url)) { ?> Olly Olly

LOL! Fixed it now :)