10 IE compatibility problems that you might not have realised

19,131 view
Added 30 May 2009, 12:48 PM

Over the year's ocProducts has maintained a private list of issues in different web browsers, and if there's one thing that is consistent it is that Internet Explorer has the majority of the problems. Sometimes they are bugs, but as you'll see from this list sometimes other browsers just do things better. I am writing this blog post not to bash Microsoft, but hopefully to provide some useful information to other web developers. Thankfully IE8 fixed a tonne of problems, and I can't wait until we can ditch IE6 and IE7, but unfortunately this will inevitably be years away; never-the-less, as far as I am aware every problem here applies to IE8 as well as older versions.

1) IE will try and guess mime-types based on file extension, even if the mime-type was specified by the web server. This can result in unexpected security holes – for example, if you allow users to upload files and you even take the precaution of saving them as ".dat" (which a default server config would serve as application/octet-stream) they could be executed in IE with Javascript by anyone who knows the URL. This is a very dangerous XSS vector – the hacker just would just need to upload a malicious file, give the URL to an IE user to open, and they could steal things like passwords from that user. Fortunately in IE8 this behaviour can be disabled but it requires explicit action by the programmer/server-admin for it to be.

2) IE does not actually support XHTML, it can't display it at all. For this reason people rarely if ever have their servers configured to send true XHTML – instead they send XHTML documents using an HTML mime-type. When you view this "XHTML" on IE or any other browser it's actually just rendered by an HTML parser. Contrary to common understanding the doctype does not specify to a browser what renderer to use. Firefox and other browsers do support XHTML, but XHTML is a lot stricter than most people realise, and if it is truly enabled people find they have made a few mistakes which stops whole pages from rendering at all (true XHTML has no error tolerance). Hopefully IE9 will support XHTML, but when people update their servers to use the right mime-type they're in for a shock. ocPortal does use XHTML, but we develop it wit the correct mime-type enabled on our test servers, to ensure it'll work.

3) You can't have "disabled" list items in a <select>. These are incredibly useful for spacing out lists for usability purposes and it's a shame they don't work right in IE.

4) In IE if you do something like:

Code

if (!xmlnode.getAttribute) continue;

you get a Javascript error. Unfortunately IE can't do this pattern across it's Active-X interfaces, even though it is valid and normal Javascript. However, fortunately you can do:

Code

if (typeof xmlnode.getAttribute=="undefined") continue;

which is better code anyway. Never-the-less, it's very easy to fall into the trap.

5) This is a really interesting one:

Code

<a onclick="window.alert('&#039;');" href="#">Click me</a>

Last time I checked, this will break on IE, but work on Firefox. It's due to the order in which entities and Javascript are parsed. Firefox is smarter, but arguably it may actually be Firefox in the wrong here.

Code

On Firefox both work, but on IE only the second works. It's a real shame, but mostly it leaves a big trap to fall into if you don't test in different browsers.

8) Firefox is less fussy about semi-colons:

Code

var foo1=function() { }var foo2=function() { }

In IE Javascript won't parse, but it does work on Firefox. I actually think Firefox should explode too (IMO there's no good reason for missing a semi-colon even if the ECMA specification allows it – it's just sloppy) – but what matters is the difference in behaviour can lead to easy bugs.

9) IE will cache the output of it's xmlhttprequest object, for scripts not marked as cacheable, whilst Firefox will not. Unless you know about this problem it is very frustrating to debug. One solution is just to append random parameter values to the URL, so that it can't be cached; however I would guess this causes cache pollution, so in ocPortal we actually output extra explicit "do not cache" headers on the server side.

10) IE (or is it Firefox?) ignores PNG-file gamma settings, meaning unless gamma settings are stripped, images get subtle colour differences on IE and Firefox. Photoshop unfortunately always uses gamma. As I mentioned I'm not sure whether it's IE or Firefox at fault here, but I always solve this by running PNG files through a PNG compression application such as PNGGauntlet, which kills two birds with one stone.

Hopefully this information was useful. I've never seen most of this stuff written about, so I thought it was worth sharing.

IE always struggles with PNG

That's right about IE and PNGs. Even though IE7 and IE8 support alpha channels in PNGs, it's unfortunately impossible to combine them with the IE opacity filter, which is something I've wanted to do a number of times. I'm hoping IE9 will support CSS 'opacity' so use of the opacity filter won't even need to be used.