Browsers - Internet Explorer

Browser diversity starts with us

Developers, designers, and strategists, here’s something you can do for the health of the web: 

Test all your sites in Firefox.

Yes, we should all design to web standards to the best of our ability. Yes, we should all test our work in *every* browser and device we can. Yes, yes, of course yes. 

But the health of Firefox is critical now that Chromium will be the web’s de facto rendering engine. 

Even if you love Chrome, adore Gmail, and live in Google Docs or Analytics, no single company, let alone a user-tracking advertising giant, should control the internet.

[…]

When one rendering engine rules them all, well, many of us remember when progress halted for close to ten years because developers only tested in IE6, and more than a few of us recall a similar period when Netscape was the only browser that mattered.

[…]

When one company decides which ideas are worth supporting and which aren’t, which access problems matter and which don’t, it stifles innovation, crushes competition, and opens the door to excluding people from digital experiences.

Debugging Internet Explorer in 2019

Even though Microsoft has explicitly told the world to stop using Internet Explorer 11, many organizations still have a significant enough IE11 user base that they have no choice but to build their products to acquiesce to the aging browser’s idiosyncratic demands.

Whether you are new to the world of building the front-end for Internet Explorer 11 compatibility or you are an old hand who knows their way around all the IE11 pitfalls, read on to learn more about:

  • Choosing the right environment for debugging
  • Dealing with unsupported JavaScript
  • Tackling CSS layout issues
  • Understanding the IE11 debugger

Armed with these tips, one should be able to quickly solve problems in the instance when a web application works perfectly on everything but IE11.

Cutting the mustard with only CSS

JavaScript can be pretty brittle, so having a way to exclude browsers that don’t cut the mustard via CSS can be really useful, especially if you don’t want to serve them large amounts of CSS that they won’t properly understand. Since we can’t prevent loading a stylesheet via feature queries, the media attribute on a <link> element seems the next best thing. Andy Kirk has come up with a few combinations:

Code language: HTML

<!--
  Print (Edge doesn't apply to print otherwise)
  IE 10, 11
  Edge
  Chrome 29+, Opera 16+, Safari 6.1+, iOS 7+, Android ~4.4+
  FF 29+
-->
<link rel="stylesheet" href="your-stylesheet.css" media="
  only print,
  only all and (-ms-high-contrast: none), only all and (-ms-high-contrast: active),
  only all and (pointer: fine), only all and (pointer: coarse), only all and (pointer: none),
  only all and (-webkit-min-device-pixel-ratio:0) and (min-color-index:0),
  only all and (min--moz-device-pixel-ratio:0) and (min-resolution: 3e1dpcm)
">
 
<!--
  Print (Edge doesn't apply to print otherwise)
  Edge, Chrome 39+, Opera 26+, Safari 9+, iOS 9+, Android ~5+, Android UCBrowser ~11.8+
  FF 47+
-->
<link rel="stylesheet" href="your-stylesheet.css" media="
  only print,
  only all and (pointer: fine), only all and (pointer: coarse), only all and (pointer: none),
  only all and (min--moz-device-pixel-ratio:0) and (display-mode:browser), (min--moz-device-pixel-ratio:0) and (display-mode:fullscreen)
">

Serving old browsers limited JavaScript and CSS

The Guardian website viewed with Internet Explorer 8: a very basic document with little to no CSS applied.
The Guardian navigation as seen in Internet Explorer 8. Unsophisticated yet functional.
nature.com as viewed with Internet Explorer 9: a very simple layout without much CSS applied.
The nature.com homepage as seen in Internet Explorer 9.

Since we’re still stuck with a small percentage of users still on various versions of Internet Explorer and other older browsers, a good way to deal with those seems to be to only serve most or all of our JavaScript and CSS to browsers that cut the mustard, leaving the older set with a basic but functional experience, without risk that our newer, shiny stuff will inevitably break, or the need for polyfills that may or may not work.

See also: Cutting the mustard with only CSS

Chrome is turning into the new Internet Explorer 6

I’m one of those weirdos who never switched to Chrome from Firefox, and the more marketshare Chrome has gained, the less inclined I am to use it for anything other than testing my sites in. I remember the days when Internet Explorer 6 was the assumed default, and I never want to see that again.

Microsoft might have celebrated the death of Internet Explorer 6, but if Google isn’t careful then it might just resurrect an ugly era of the internet where “works best with Chrome” is a modern nightmare.

Should I try to use the IE implementation of CSS Grid Layout?

If you are using Grid in a very simple way, and positioning items rather than using auto-placement then the fact that grid exists in Internet Explorer from version 10 could turn out very useful. You could certainly use this in order to create a simpler layout for IE10 and up, once Grid is shipped in other browsers.

However be aware that this is going to require some additional testing and work, you are unlikely to be able to simply rely on Autoprefixer to run and do the work for you. For example, if you have used auto placement for any item and then don’t set a position using the -ms properties, that item is going to stack up with any other unpositioned items in the first grid cell.

The good news is that the IE implementation is pretty much frozen in time between IE10, 11 and current versions of Edge (presumably until Edge updates to the new specification). So work you do to implement grid in IE should work in those versions without needing to do different things for different IEs.