Goodbye, Internet Explorer 11
Hi there! My name is Lisa Xu, and I’m a software developer for the Atom platform team at Kaplan Test Prep. I am passionate about building a great user experience using the latest technologies (such as flexbox, grid, and css-variable). I am usually in charge of making UI components and styling them so they look good. Today, we’re going to talk about ending support for Internet Explorer and restoring sanity to UI developers everywhere.
Browser Support
As I have been working on building the platform with the team using the latest web technologies, we started running into compatibility issues.
CSS Variables: Our Product Owner didn’t upgrade her Safari version and while testing, and discovered that css-variable is entirely broken on Safari 9. Turns out that doesn’t work in IE either. To fix this, we started using polyfills.
Grid: Grid, like css-variables, also doesn’t work in Safari 9. It has partial support in IE but is missing grid-template-areas, a feature I used several times in the platform.
Flexbox: One of the pages was styled using flexbox, and all the child content were bunched together and the container was actually much smaller than the content size. Turns out, that’s a bug with IE, and Microsoft marked this bug as “will not fix.” I tried some of the user-documented workarounds around the internet, but they didn’t work for my particular case. If I had to get that page to a working state in IE with anything remotely resembling our design, I’d need to fall back to display: inline-block.
Or floats. Gross.
This wasn’t going to be one of those elegant three-line solutions I’ve done for the other parts of the app either. I’d have to just write a fully different set of styles for IE, and that’s not particularly exciting.
I’m done with IE
I was considering the least painful solution when one of my colleagues showed me something: he went on Github on IE and noticed that Github had a message up top that let the user know IE isn’t supported. Github is owned by Microsoft! Why are we supporting IE when a Microsoft product doesn’t?
I asked my Product Owner about what percentage of traffic actually comes in from IE, and it turned out to be roughly 2.5%. Pretty low. We got the go-ahead to stop support for IE.
No more IE!
This is great because we can finally push forward and use the fun and new CSS technologies like flexbox and css-variables and grid andmask — flexbox isn’t even that recent — and though sometimes we may still need to write a fallback or two for older Safari, it’s nowhere the same level of effort required for IE. Discontinuing support for IE allows us to put valuable dev effort into moving forward on the platform and being able to use the latest technologies. Even Microsoft is moving to Chromium for Edge, after all these years.
Once we got the go-ahead, it was time to think up some approaches. Doing an Angular component is out — Angular needs all those polyfills in polyfills.ts to be uncommented for Angular to actually run on IE, and if our goal is to discontinue IE support, that seems counterintuitive. Why run something that gives overhead to support a browser when we’re actually not supporting this browser? So we had to think of another solution.
ES6 doesn’t work in IE, but IE9-IE11 does work with ES5, so that’s a good place to start, and if you’re using IE8 or below I don’t know what to say… I wanted the blocker to be easily usable with any framework (or lack of), so I figured writing a vanillaJS script in ES5 would be the most usable option.
While still exploring the component/service library option I turned on the polyfills in polyfills.ts just to see the app running in IE, and I did end up reading all the comments. I learned that polyfills.ts executes before the main application code, and because the polyfills it contains can support IE9–11, I figured it would be a good place to import my IE Blocker. I tested it out with a quick alert call, and it worked.
I wanted to avoid any extra imports beyond this one script, so I built the DOM directly in the javascript and injected it into <body>, and styled it by injecting a style tag into <head>. I don’t recommend doing this in large-scale projects that require maintenance one bit, but given that this is a lightweight single-screen message, I thought it warranted that treatment.
Next, I needed to prevent Angular from executing its actual main application code. While the application I tested the blocker on entirely doesn’t work in IE, other parts of our platform do partially work, and I wanted to guarantee to stop any extra API calls. Unfortunately, in my research, I did not find a way — and I don’t think there really is one — to stop the execution of another Javascript file from a Javascript file, so I ended up removing <app-root> and anything else from<body> to prevent Angular from doing anything. This may throw an error in console (for the IEs that do have a console) but it’ll stop API calls and half-baked DOM rendering, which is what’s really important.
After I finished the blocker, I used the same polyfills method to inject this page across the platform. Here is the npm package [@atom-platform/es5-ie-blocker]. I hope other developers will find this useful as well to move off of IE and be free to use the latest CSS technologies, free from all the IE-related bugs.
Demo on how to use it in Angular apps: [Stackblitz]
Suggestions on how to make it work better with other frameworks are welcome!
