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. My favorite resource for conditional comment examples is on Quirksmode.
Once this markup is in place, you have a convenient way of targeting styles to specific versions of IE via CSS. 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. I wrote a blog post on that very topic.