CSS pre-processors – The starting line

If you were to look back on the big developments in web design over the past year one of the biggest changes would be that of the apparent mainstream adoption of CSS pre-processors.

CSS pre-processors allow more complex programming code to be used when writing CSS. Commonly these allow the addition of variables, loops, mathematical operators and more. The pre-processor will then automagically take this complex code and transform it into traditional CSS for use in a website.

Noise

It’s been hard to ignore the increasingly vocal supporters of CSS pre-processors. It’s reached a level whereby it has created an impression that those still writing vanilla CSS are now in the minority. In an attempt to keep up with the larger community even those unconvinced by pre-processors are beginning to adopt them into their workflow.

In web design there is a feeling of necessity in keeping up with the larger community, somewhat transferring your decision making to the larger group rather than investigating the options for yourself.

A personal view

This article is to highlight my scepticism in adopting CSS pre-processors into my own workflow. My research into pre-processors did start as a result of seeing so many others talking about them but it’s only after nearly a year that I’m now making the jump.

One of my biggest issues was that I’ve always retained a level of control over my CSS and never seen the need for external assistance through things like CSS frameworks. By adopting a pre-processor I lose some of the control I currently wield over all of my CSS.

But I need to test the waters and really see if this concern is all that valid and with there being so many advantages to CSS pre- processors I had to, at some point, give it a go.

The good thing about CSS pre-processors is that if I wanted to I could write the same CSS I always have and not use any of the additional features available. Of course this would be pointless but it does mean I can slowly adopt the features as and when I desire.

The feature I’m most concerned about is nesting. This allows you to nest child CSS rules within their parent. On the face of it this seems like a great idea to reduce the amount of code a person writes but the output when nesting multiple times could harm efficiency, file sizes and speed so needs to be carefully judged.

On the other side of the coin the simple ability to specify variables and more easily deal with vendor prefixes will speed up the time it takes me to write CSS for a website.

SASS or LESS

SASS and LESS are different pre-processors which both work a little differently but in general do the same job. I’ve chosen to try SASS for a couple of reasons:

• SASS appears more widely adopted by CSS experts and thus more help and resources exist
• The SASS vs LESS article on CSS Tricks makes a solid argument in favour of SASS
• In installing Scout I can more easily integrate SASS into my existing workflow

What Scout does is listen for changes to .SCSS files which contain the code I would write and then process this file into traditional CSS files when changes are made.

Here goes

It’s with a little trepidation I start using SASS today on a new ecommerce project. Normally I would trail new technology like this on internal projects but to get the most from a pre-processor a larger project is required.

Once I’ve finished I’ll write a follow up to see just how much of SASS I used and whether in using SASS my fears over the disadvantages of using pre-processors were largely unfounded.