HTML Logo by World Wide Web Consortium ( Click to learn more about our commitment to accessibility and standards.

Moving forward with Composr

ocPortal has been relaunched as Composr CMS. ocPortal 9 is superseded by Composr 10.

Head over to for our new site, and to our migration roadmap. Existing ocPortal member accounts have been mirrored.

10 IE compatibility problems that you might not have realised

10 IE compatibility problems that you might not have realised 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:


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:


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:


<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.

6) You can't do the following in IE:


var array=[1,2,3,];
due to the final comma. However, in other browsers it works.

7) This is a very common problem:


var element=document.getElementsByTagName('select')[0];
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:


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.

View all


There have been no trackbacks yet