Goodbye CSS, Hello Less

Thoughts Design Technology

I’ve recently made the switch to using a CSS pre-processor and I can definitely say it’s for the better. Here are my top reasons why LESS rocks.

I have finally taken the plunge into using a CSS pre-processor. If you’re not familiar with these, the concept is that you have a language similar to CSS in which you code the style rules for your site. This language then gets compiled into pure CSS for inclusion, as usual, in your HTML code.

Why would you want to do this? Doesn’t that introduce another, unecessary step? Isn’t CSS just fine the way it is? Perhaps. You might enjoy using CSS as a purely declarative language, but once I started using LESS (my pre-processor of choice), I very quickly decided I was not going back. Here’s why.

A Few Reason To Like LESS

Variables

This, alone, is worth using a pre-processor for. It allows you to declare a variable (for example a background colour) and then re-use that colour without having to do a find-and-replace every time you want to tweak it. LESS handles this like so:

@backgroundColor: #000;

body {

    background:@backgroundColor;

}

Functions

One of the constant problems with using pure CSS (for me anyway) is that of changes to colour palettes. If your colour palette specifies that your text colour is related (by saturation or lightness for example) to another colour, making changes to either of them usually requires the use of an external tool to keep your colour balance working nicely. This quickly becomes tiresome, and prevents you from designing in the browser (which is one of the ways I like to work). With LESS, you can do things like this:

header {

    background:lighten(@backgroundColor, 10%);    

}

LESS provides a whole range of useful functions to work with colours, font sizes, and general layout measurements. This makes the process of building up colour palettes, typography and layout so much easier, and means that you can, for example, change your base colour without mucking things up. Mixins

LESS allows you to re-use various bits of CSS code, by simply referencing them. For example, if you had a particular style defined for a class like this:

div.panel {

    border-top:1px solid @borderColor;
    padding:20px;
    float:left;

}

you could simply reference this code somewhere else in order to pull in all those style declarations:

footer {

    .panel;    

}

LESS even provides you with a way to make these mixins work a bit like functions by passing arguments to them so that you can define colours, and sizes outside of the mixin.

Mixins make the process of dealing with vendor prefixed CSS rules a lot simpler, because you can define all the vendor prefixes in the mixin and then just pull in a one line reference to that, rather than repeating all the various codes for the different browsers, anytime you want a drop shadow.

Structure

This really suprised me. I didn’t think I would use this feature much, but actually, it’s been the thing I’ve come to love most about LESS. Essentially, LESS allows you to nest rules, meaning that you can be very specific in your CSS rules (which I like). This comes most in handy when you want to more easily keep track of which rules are working on a particular section of your page.

#main {

    background:@bodyBackgroundColor;
    padding:20px;

    header {

        color:@headingColor;

    }

}

I particularly like the way that you can also use this syntax to specify things which are comginations rather than heirarchies. For example, one of the most common CSS tasks is to define link states. Normally, you’d do that like this:

a {

    color:#900;
    text-decoration:none;

}

a:hover {

    text-decoration:underline;    

}

With LESS, you can do the same thing like this:

a {

    color:@linkColor;
    text-decoration:none;

    &:hover {

        text-decoration:underline;    

    }

}

This might seem like a trivial change, but believe me, when you’re dealing with a large, complicated CSS file with lots of different styles in different sections (and media queries thrown in), it makes it much easier to keep track of things.

Debugging

LESS gives you compile errors, which will tell you where that missing semicolon is. This is a big thing for me. I’ve lost track of the number of hours I’ve spent over the last few years, trying to hunt down a CSS syntax error. Mostly they’re pretty quick to find, but they all add up, and a debug message is a great thing. It Makes You Think Differently

LESS allows you to actually remove some of the non-semantic stuff from your HTML. We’ve all grown accustomed to using classes to set out grid layouts and all sorts of not-strictly-semantic stuff. With LESS, you could theoretically produce a completely semantic HTML file which includes things like a grid layout (by using mixins for example) without the pain and suffering that would be caused if you tried to do that in pure CSS. Note that I say could because I’m not yet doing this. For me, the semantic compromise with things like grids works ok, and I’m not prepared to change my workflow that dramatically yet. If it matters to you however, you could solve that problem with LESS.

The other thing I’ve noticed about the way I’ve been coding my styles since switching to LESS is that I’ve started to think about CSS like it’s proper code instead of a bunch of rules. You might argue that I, perhaps, should have been doing that already, and you would have a fair point. Still, less has made my page styles more efficient, sophisticated, and, most importantly for the busy web designer, easy to read.

I’m never going back.