CSS pre-processing with LESS

While I spend much of my time elbow deep in a mixture of PHP, ColdFusion and .NET I probably spend about 60% of my time cringing at the state of old websites CSS and writing new stylesheets and I try my best to keep up with the latest front end technologies and for the last 6 to 8 weeks I have been using (and abusing I must admit) LESS which has in my opinion been an absolute god send, from both a management and developer point of view.

Gripe…

It allows the use of mixins, variables and adopts a fairly DRY methodology, until you render.

I’ll get the gripe over with before I move onto some of the plusses of LESS; during any CSS writing I’ll try to visualise the formation of my selectors so that I can maximise the effect of DRY and for years and years that has worked for me, so when I heard about LESS, researched it I was gob-smacked to see I could write arrow-head formated code and not generally have to worry about repeating selectors over and over. This was all until I came to compiling, take this LESS snippet for instance:

#myunorderedlist {
    //Clear the element
    overflow:hidden;
    border:1px solid #F00;

    li {
        float:left;
        border-right:1px solid #F00;

            a {
                padding:8px 20px;
                text-align:center;

                &:hover {
                    cursor:pointer;
                    text-decoration:underline;
                }
            }
    }
}

Will end up like this, with a lot of repeated selectors that aren’t exactly necessary:

#myunorderedlist {
    overflow:hidden;
    border:1px solid #F00;
}
#myunorderedlist li {
    float:left;
    border-right:1px solid #F00;
}
#myunorderedlist li a {
    padding:8px 20px;
    text-align:center;
}
#myunorderedlist li a:hover {
    cursor:pointer;
    text-decoration:underline;
}

This isn’t a massive issue for me, I recently said for everything good out there, there is something twice as bad and twice as stupid so I took this with a pinch of salt and hit the drawing board to try and think of a way to morph my working method into something to reduce this. I failed. But having said that, the amount of time saving involved with the use of mixins is fundamentally one of the biggest time savers of my day and the ability to organise my CSS into separate files and compile out to one is something of a miracle.

@imports make me shudder..

Now, normally when I see @import ‘some-file.blah’; I feel a little sick and shaky, these are a personal hate of mine. I have no idea why, but I hate these but LESS has taken it to another level and allowed for *.less inclusions which on compilation are actually written to the callee.

Take the below code for example:

@import 'effects.less';
//For anyone out there reading this, NORMALISE stop resetting!!  
@import 'normalise.less';
@import 'html5.less';

html {
    min-height:100%;

    body {
        min-height:100%;
    }
}

@import 'home.less';
@import 'about.less';
@import 'services.less';

So I’ll take it from the top, the other day I made public a CSS3 effects bootstrap that is cross browser (of course excluding IE) and I import that into every project that I think is going to use any kind of transitional effects (which lets face it is becoming more and more popular/regular) this file contains nothing but a disclaimer and a set of mixins to make my job easier and faster and if I don’t use any of the functions the disclaimer is the only thing that is output in the CSS.

I NEVER reset, sorry Eric Mayer you’re a legend but its not the best anymore. I normalise which I find much better and I’ve got my own LESS file for this, just run the CSS > Sass converter tool to convert this to LESS and tidy it up a bit.

In the example I set a few basic rules on the html and body tags, this was just representational so you don’t need these; I then start importing my page specific files.

The actual ability to import page specific stylesheets is brilliant (in the sense it ends up in the same file) although it does create an unhelpful amount of bloating but its quicker than writing plugins for CMS’ to attache specific stylesheets to pages. It also allows for more than one person to work on a website and compile to the same file with no loss of data which is brilliant for where I work and what I do.

Opinions on other issues

A few people mentioned that the use of debug toolbars (Firebug, webkits toolbar, Dragonfly, etc) to check css layouts is annoying when using CSS pre-processors as 100% of the time the line-number is wrong making it difficult to find the actual line of code that is wrong. Big deal I say, organise your code more efficiently using LESS imports and mixins/variables or any other way you find beneficial.

Its also been heard that LESS/Sass makes front end developers code lazily, I completely disagree with this. I find it incredibly hard to code lazily with LESS as the arrow-head formation makes it easy to read and search through so amends are easy to implement, also with the ability to use JavaScripts // comment syntax you can clearly label your selectors to something more memorable to search by or note a change made/original value.

Conclusion

LESS/Sass and in general CSS pre-processors are great for some projects, perhaps not all but definitely a time saver for me 80% of the time, it requires no training because it is just far too easy to use. For any HTML5 or CSS3 projects its almost an absolute must with the likely-hood of falling into the no-DRY hole, easily fixed with imports and libraries containing different effects its a dead-cert that you’ll love using LESS but find it gainful only half of the time depending on your work type.

Give it a go, after all its free and it takes no time at all to learn it. Also download Crunch its the best LESS editor/compiler currently available. Even if it doesn’t work on Ubuntu just yet