Compatibility Mode: What Any XPages (or Web Developer) Needs To Know
This rant is not the result of any individual project,I’ve been meaning to write it for a while. It’s also as much out of disillusionment of believing web developers who say you can switch off compatibility mode, because it’s not what happens necessarily.
When developing for a corporate environment, the default browser is usually Internet Explorer. Internet Explorer has always required a lot of hacks, so much so that in the past traditional Domino web applications for internal use were sometimes designed only for IE. But in the XPages world (or most web development that uses some kind of framework), mostly we don’t have to worry about those hacks any more.
But we still have to deal with one abomination (sorry, but it’s so horrendous I cannot bring myself to use anything more polite).
Often there are policies in place to force intranet sites into Compatibility Mode. So as a web developer, you developer and test against a proper browser – one that has proper developer tools to help you diagnose problems, not something that’s just called Developer Tools. Then you come to look at it on Internet Explorer…and weep!
Because you realise that in the post-IE6 world, modern web development uses techniques such as float to position content. But there are other aspects as well, as you’ll see. You realise the cause of your woes is that IE9 is running compatibility mode. So you’ve been developing a web application that should look like this, and does look this in any other browser.
But certain bits of functionality and look and feel don’t work quite how they should. That’s because it’s forced into Compatibility Mode. So the Browser Mode shows as IE9 Compat View, the Document Mode as IE7 standards (“standards”!), and the user cannot change it out of Compatibility Mode, as you see below:
But thankfully a quick search of the internet gives a host of experts who tell you how to switch compatibility mode off.
Or so you think.
You’ve probably seen the code. So on an XPage, the beforeRenderResponse would set a header:
var exCon = facesContext.getExternalContext();
var response = exCon.getResponse();
The isIE parameters may vary and IE=edge is not recommended (that forces it into the most recent for the relevant IE version, which you may not have tested). But whatever the parameters that are chosen and regardless of what people tell you, it doesn’t switch off Compatibility Mode.
It changes the Document Mode, but leaves Compatibility Mode switched on.
And that’s not the same. If you want proof, compare the screenshot below to the first screenshot. This app had the code above. I defy anyone to claim it looks the same.
The ideal solution would be that, if companies still need a Internet Explorer in Compatibility Mode for legacy intranet applications, deploy that but also deploy a modern browser for modern Domino XPages applications within the intranet. Or better still, ensure those legacy applications are displayed in Compatibility Mode either by adding code to force Compatibility Mode or getting users to change it.
Otherwise, the cost and the pain of supporting legacy intranet applications burdens modern developers.