Happier IE fallbacks with CSS, LESS and conditional comments

Nobody likes writing CSS fallbacks. They’re a speed bump in your creative flow. Here’s how I use a couple different techniques to simplify the process

This assumes that you’re using conditional comments on the html tag to define classes for certain versions of IE. This technique was originally proposed by Paul Irish and refined in the HTML5 Boilerplate to something like this:

<!--[if lt IE 7]> <html class="no-js lt-ie9 lt-ie8 lt-ie7" lang="en"> <![endif]-->
<!--[if IE 7]>    <html class="no-js lt-ie9 lt-ie8" lang="en"> <![endif]-->
<!--[if IE 8]>    <html class="no-js lt-ie9" lang="en"> <![endif]-->
<!--[if gt IE 8]><!--> <html class="no-js" lang="en"> <!--<![endif]-->

You can omit the “no-js” class if you aren’t using Modernizr, and feel free to remove or tweak the conditional comments to suit the versions of IE that actually require fixes (I recommend referring to this Quirksmode post for examples).

With this markup is in place, you can conveniently target styles to specific versions of IE. For example, let’s say I’m running into a box model bug in IE7 that’s resulting in a div not having the correct amount of top margin. Thanks to the classes I’ve applied using conditional comments, I can apply extra margin only for that browser version and below.

.example { margin-top: 24px; }
.lt-ie8 .example { margin-top: 48px; }

Voila! .example will have extra margin to account for the bug in IE7 and below without impacting any other browsers.

Vanilla CSS works well for a simple, top-level item like that, but it can get a bit hairy when you try to apply similar fixes with particularly deep inheritance. An example:

.l-container.example.s-active .button {
    background-color: #00ccff;
    display: block;
    line-height: 42px;
}
.lt-ie8 .l-container.example.s-active .button {
    height: 42px;
}

Yeesh… that’s pretty verbose! Here’s where the beauty of LESS comes in handy, particularly its support for scoped variables, nested rules and the ampersand combinator:

.l-container.example.s-active .button {
    @height: 42px;
    background-color: #00ccff;
    display: block;
    line-height: @height;
    .lt-ie8 & {
        height: @height;
    }
}

Occurrences of @height will be replaced with 42px in the compiled CSS. The ampersand in the nested selector will be replaced by the parent selector. This will compile to exactly the same as the previous example, but with a lot less redundant typing.

That’s all well and good for one-off bug fixes, but what about recurring fixes that need to be applied on a case-by-case basis? That’s where the power of parametric mixins comes in handy.

Here’s an example of a mixin we can use to support transparency in old IE syntax and standard syntax. Note that because IE’s filter property does not use standard CSS syntax, it can throw off the LESS parser, so we use a leading tilde (essentially the LESS equivalent of eval) and string interpolation to render the rule:

.opacity(@amount) {
    opacity: @amount;
    .lt-ie9 & {
        @ieop: @amount * 100;
        filter: ~"alpha(opacity=@{ieop})";
    }
}

.example { .opacity(0.5); }

Which will compile to:

.example { opacity: 0.5; }
.lt-ie9 .example { filter: alpha(opacity=50); }

Here’s another example for supporting inline-block in IE7 and below:

.inline-block() {
    display: inline-block;
    .lt-ie8 & {
        display: inline;
        zoom: 1;
    }
}

.example { .inline-block(); }

Compiled:

.example { display: inline-block; }
.lt-ie8 .example {
    display: inline;
    zoom: 1;
}

Like The Force, nested rules can be used for good or for evil. When working with this sort of shorthand it can get a little too easy to overuse mixins or forget to combine selectors to insure your compiled CSS is still fairly lean. Refer to this entry for more on that very topic.

Responses

Harvey Ramer says

This is a very simple and elegant solution. How does it affect validation?

Responded

Tyler Sticka says

Non-standard CSS properties like filter will still trigger a validation error, just like they always have if included in your main (unconditional) stylesheet. Because of the popularization of non-standard, vendor-prefixed properties and the lack of competing implementations of filter and behavior, I’ve decided that’s not a big issue for me, but certainly something to be aware of.

Responded

Brian says

Excellent clear post! Very useful technique. Thanks!

Responded

Omri Barkai says

Wow thanks! this is a really good way to handle IE only CSS. Keeps the style sheets nice and organized. Good job!

Responded

Leave a response

Your email address won’t be published. You can use some HTML or Markdown.