We recently deployed a new version of our catalog front end (Rails, Blacklight), which is based on Bootstrap 3 CSS.
Bootstrap3 supports IE10 fine, IE9 mostly, and IE8 . IE8 has no media queries out of the box, so columns will be collapsed to single-column small-screen versions in Bootstrap3’s mobile-first CSS — although you can use the third party respond.js to bring media queries to IE8. We tested IE8 with respond.js, and everything
IE7 according to bootstrap “should look and behave well enough… though not officially supported.” We weren’t aware of any on-campus units that still had IE7 installed (although we certainly can’t say with certainty there aren’t any), and in general decided that IE7 was old enough that we were comfortable no longer supporting it (especially if the alternative was essentially not upgrading to latest version of Blacklight).
I did do some limited testing with IE7, and found that our Bootstrap3-based app definitely, as expected, fell back to a single column view on all monitor sizes (IE7 lacks media queries). In a limited skim, all functionality did seem available, although some screen areas on some pages could look pretty jumbled and messy.
Meanwhile, however, Bootstrap also says that “Bootstrap is not supported in the old Internet Explorer compatibility modes.”
What we did not anticipate is that some units in our large and hetereogenous academic/medical organization(s) use, not only a fairly old version of IE (we were able to convince them to upgrade from IE8 to IE9, but no further) — but also one that was configured by group policy to use ‘compatibility mode’ for all websites. IE9 would have been great — but ‘compatibility mode’ not so much.
They reported that the upgraded catalog was unuseable on their browsers.
The bootstrap web site recommend adding a meta tag to your pages to “be sure you’re using the latest rendering mode for IE”:
<!-- note: not what we ended up doing or recommend -->
<meta http-equiv="X-UA-Compatible" content="IE=edge"
However, we didn’t have much luck getting this to work. Google research suggested that it probably would have worked if it is placed immediately after the opening <head> tag (and not in a conditional comment), to make sure IE encounters it before its ‘rendering mode’ is otherwise fixed. But this seemed fragile and easy for us to accidentally break with future development, especially when there’s no good way to have an automated test ensuring this is working, and we don’t have access to an IE configured exactly like theirs to test ourselves either.
What did work, was sending that as an actual HTTP header. “X-UA-Compatible: IE=edge,chrome=1”
In a Rails4 app, this can be easily configured in your config/application.rb:
config.action_dispatch.default_headers.merge!({
'X-UA-Compatible' => 'IE=edge,chrome=1'
})
After adding this header, affected users reported that the catalog site was displaying manageably again.
Also, I discovered that I could mimic the forced compatibility mode at least to some extent in my own IE11, by clicking on the settings sprocket icon, choosing “Compatibility View Settings”, and then adding our top level domain to “Websites you’ve added to Compatibility View.” Only top-level domains are accepted there. This did succesfully force our catalog to be displayed in horrible compatibility mode — but only until we added that header. I can’t say this is identical to an IE9 set by group policy to display all websites in compatibility mode, but in this case it seemed to behave equivalently.
I think, with enough work on our CSS, we could have made the site display in an ugly but workable single-column layout even in IE8 with compatibility mode. It wasn’t doing that initially, many areas of pages were entirely missing. But it probably would have been quite a bit of work, and with this simple alternate solution it’s displaying much better than we ever could have reached with that approach.
Bibliographic Wilderness 