Make Internet Explorer Cross Browser Testing Less Painful With SCSS

We’ve all been there. We don’t want to do it, we don’t think we need to do it, but it’s necessary. Unfortunately, Internet Explorer (11) is a necessary evil for most business requirements. Certain businesses even require earlier versions than that. *shudder* Fair warning, this article is only keeping the most recent version(11) in mind. If you need to support earlier versions, some tweaks to these examples may be required.

So you’re tasked with supporting Internet Explorer. For the most part, it’s pretty straightforward. While Internet Explorer does have its own quirks, Internet Explorer 11 isn’t that bad. You may find that it requires its own media queries. Things will seem to be going alright until you open a layout to reveal a total mess.

This probably will happen. Relax, take a deep breath. Most Internet Explorer problems I’ve encountered are usually fixed with a few simple techniques. In this article, I will go over simplified media queries you can use and common extends for solving most UI problems. Let’s get to it!

Crash Course: IE Specific Media Queries

There will come a time when you realize Internet Explorer requires its own tweaks. What I mean by that is a specific style that only Internet Explorer needs. Firefox, Google Chrome, Edge, etc won’t require it to function correctly, so we shouldn’t risk modifying how your code works on these browsers.

Ideally, the CSS should be structured so it works consistently across all browsers, but that can’t always be the case. Sometimes it’s easier and quicker to give Internet Explorer elements its own height, width, margin, and so on.

How do we only give it to Internet Explorer? The same way we’d exclusively give styles to mobile screen sizes: media queries!

//This query exclusively targets Internet Explorer
@media all and (-ms-high-contrast: none), (-ms-high-contrast: active {
    @content;
}

//Additionally, you can target anything *except* IE using @supports
@supports not (-ms-high-contrast: none) {
    @content;
}

The media queries are pretty straightforward to implement. However, it is not super clear what they do upon first glance, and they are a bit verbose. If you have lots of layout code, these can quickly scatter across your files. Ideally, you should unify them. Luckily, this is pretty easy with SCSS mixins.

@mixin ifIE() {
    @media all and (-ms-high-contrast: none), (-ms-high-contrast: active) {
        @content;
    }
}

@mixin ifNotIE() {
    @supports not (-ms-high-contrast: none) {
	@content;
    }
}
.container {
    p {
        @include ifIE {
            width: 100%;
        }
    }
}

With these mixins, utilizing the media queries is crystal clear(see above). You can name these mixins whatever makes most sense to you. This keeps a good amount of IE-specific code out of your main files. Good deal! Also, you can outsource these mixins to a global file for better code organization.

Utilizing @extends to Implement Common UI Fixes

Internet Explorer can be tricky and require weird hacks, but not always. A good amount of the time, all you really need to do it give the problem elements an explicit width or height. Below is a few @extends I use to reduce repetition.

%ie-full-width {
    @include ifIE {
        width: 100%;
    }
}

%ie-full-height {
    @include ifIE {
        height: 100%;
    }
}

%ie-paragraph-fix {
    p {
        @extend %ie-full-width;
    }
}
.example-section {
    @extend %ie-paragraph-fix;

    .inner-div {
        @extend %ie-full-height;
    }
}

This of course, is not completely necessary. However, I try to quarantine as much IE-specific code as possible. Instead of a common 3-5 line fix, you can @extend it with just one. If you come up with any other helper methods, you can simply add more yourself!

In my case, these 3 mixins have solved most cases and have saved lots and lots of code. If an element does require a specific hack, just use the mixin and add your own styles. Keep it simple!

Wrapping It Up

You can simplify IE encapsulation by making easy to read mixins. If there’s a common UI fix that’s used across multiple files, you can make a global @extends file. That’s all there is to it! Unfortunately, things aren’t always this simple. When they are, it’s nice to have a clean way to approach it so you can get to the trickier bugs. Hopefully this can make your cross-browser testing experience that much less painful 🙂

Leave a Comment