Archive | IE Compatibility Mode RSS for this section

CSS Tip: Dealing with Table Spacing in IE Compatibility Mode

One of the most frustrating things about dealing with IE compatibility mode is how it handles table layouts. In my recent experience, it seems to automatically stretch them out to take up more room than you’d expect. It seems to generally disregard padding, spacing, and column width CSS settings (unless the column width is greater than the amount of space the browser wants to provide for a column).

Even worse, it doesn’t always space the columns evenly. In a recent application, cells with consistent content were sized differently in compatibility mode, so the content of some cells would wrap and others wouldn’t — even though there would have been plenty of space for all of the data if the columns had been spaced evenly.

Since the pattern seems to be that it will stretch tables out to the full available width, the quick workaround to improve table layouts in compatibility mode is to put a container around the table (such as a div) and use CSS to fix the width of that container. This doesn’t cause it to space the columns perfectly, but it can be very handy in limiting the size of the table as needed.


XPages Tip: Dynamically Loading a Style Sheet for IE Compatibility Mode

I’ve wrestled with IE’s compatibility mode (which makes higher versions of IE act like IE7) a few times recently. Some workarounds I’ve come across were documented previously. In this post, I’ll show how to conditionally load a style sheet that has styles specifically for compatibility mode.

Themes to the Rescue

Fortunately, you can determine the browser and version in XPages and you can use a theme to conditionally load a style sheet based on the browser and version.

The snippet below will load one style sheet if the browser is IE7 (or below) and load another style sheet if the browser is anything else.

The .isIE(0,7) method returns true or false based on whether the current browser is any version of IE from 0 to 7.

<resource rendered="#{javascript:context.getUserAgent().isIE(0,7)}">
<resource rendered="#{javascript:!context.getUserAgent().isIE(0,7)}">

It’s a massive headache to deal with compatibility mode, but this flexibility makes it a little easier to adjust styles as needed.

XPages Tip: Fixing a Few Problems Caused by IE Compatibility Mode

I recently worked on a project that was required to support IE8 and IE9 (along another more competent browser). However, when it was deployed, it rendered in compatibility mode (per the corporate standard configuration), which really caused it to act like IE7. In this post, I’ll describe a few specific issues that we found with compatibility mode and how we worked around them.

First Attempt

The first thing we tried was this great XSnippet to change the response header to try to force the browser out of compatibility. I’ve seen it work in tests, but it didn’t work in this client environment, so we had to work around the most important side effects that compatibility mode caused.

Application Layout

Problem: Using the standard application layout control, some views (the content section of the layout) would display below the navigation menu, rather than to the right of it, but only in IE with compatibility mode enabled.

Workaround: To fix this problem, ran code onClientLoad to check the browser and version on the affected pages and shrink the width the content area slightly, which fixed the problem. (Credit to Wil How for this solution.)

Date Pickers

Problem: The strangest side effect that we saw was that clicking on any date picker caused a form submission and full page refresh.

Workaround: We changed all of the date pickers in the application (i.e. standard inputText fields with the date picker added) to Dojo Date Text Box controls in order to avoid this behavior.

Font Awesome

Problem: Font Awesome icons did not render in compatibility mode. Font Awesome actually comes with IE7-specific style sheets, but they didn’t work in compatibility mode, either.

Workaround: From what I’ve read, it appears that the problem lies in the length of the url used to define the font. As it turns out, adding a hash (#) in the url allows older versions of IE to process longer URLs. The fix was to add #iefix into the second source line in the font declaration in the font-awesome style sheet, as shown below.

@font-face {
  font-family: 'FontAwesome';
  src: url('../font/fontawesome-webfont.eot?v=3.2.1');
  src: url('../font/fontawesome-webfont.eot?#iefix&v=3.2.1') [...More font definitions here]
  font-weight: normal;
  font-style: normal;


Problem: This problem appeared to be that a dojo progress bar dijit didn’t work in compatibility mode, but I tested it separately and it worked fine. As it turned out, it was failing where code tried to use array.indexOf() (only in compatibility mode) as it was building the data to update the progress bar.

Workaround: Replaced the convenient array.indexOf() calls with code to actually walk through an array and check whether any of the values match.

Got Tips?

I’m sure there are many, many more issues causes by compatibility mode in your applications. Got any tips or links to share?