Stuff & Nonsense. Website designers in North Wales

LESS

About two years ago, I tweeted “If your CSS is complicated enough to need a compiler or pre-processor, you’re fucking doing it wrong!” I meant it too. After-all, CSS isn’t hard to learn and it’s easy to write and write quickly. So why would you need a processor like LESS or Sass?

People reacted (as they do) telling me I was wrong. I wasn’t oblivious to their enthusiasm, so I pulled up the Sass website, ready to dive in. Wait.

First of all, let’s get Sass up and running. If you’re using OS X, you’ll already have Ruby installed. Windows users can install Ruby via the Windows installer, and Linux users can install it via their package manager. Once you have Ruby installed, you can install Sass by running gem install sass.

Sorry, what? Now you can berate me for not understanding the Terminal if you like, but I’ll trade your ruby gems for my under-colour removal and dot gain, any day of the week. How hard should this be? Really?

sass --watch style.scss:style.css
sass --watch stylesheets/sass:stylesheets/compiled

That hard. Obviously.

If you were watching Twitter that night, it wasn’t just the interface that was blue. Chris Eppstein was watching. He kindly offered to help, so I turned my Mac over to him and I watched as he remotely flew through Terminal commands and listened while he tried to explain why I couldn’t see anything that he was installing where I expected it to be — in my Applications folder. Boy did this seem like a lot of work. I just didn’t get it.

Nathan Borror didn’t think Sass was for him either. Not because he shared my Terminal phobia, but because CSS shouldn’t be so complicated as to need Sass anyway.

Why the frak do I need control directives in CSS? If I’m using a @for loop to generate styles I’m doing something very wrong. CSS is not a programming language, it’s a style language and the preprocessor community should keep that in mind.

Jeff Croft summed it up well, commenting on Nathan’s post.

There are a few reasons for this:

Most CSS gurus aren’t programmers. When they start seeing logic, variables, mixins, and other programming constructs in their style sheet, they freak out a bit.

CSS gurus are just that: CSS gurus. They already know how to write their way out of any paper bag you can find using CSS. They’re experts. They don’t need a preprocessor. Developers are writing these things because, for them, CSS is confusing and missing useful functionality. But CSS gurus don’t look at CSS that way. Most CSS gurus think CSS is, by and large, pretty darn great. Sure, we have little nits to pick, but for the most part, CSS works for us, and we know how to bend it to our will.

To the typical CSS designer, the command line is a frightening place.

Even a simple CSS guru knows that code generation reeks of inelegance (not saying Sass is inelegant or that there aren’t good examples of code generation … just that, as a concept, it scares people).

Fast forward to this summer. I’m now primarily working with clients in week long agile design/development sprints, so I need to be faster and have more flexibility when I’m writing CSS. With clients’ budgets squeezed, I also want to spend more time being creative and less reinventing code.

When Twitter released their Bootstrap it came with set of LESS files, which prompted me to take at LESS. A few days working with it and I was converted. These days I’d be loathed to work without it.

One of the reasons that LESS works for me is that — although I could use a Javascript or server-side compiler if I knew what the hell $ npm install less@latest meant — there’s several desktop applications that compile LESS files to CSS without me needing to go anywhere near a Terminal. (Sass has a desktop app now too but, not being a Sass user, I can’t tell you how well that works.) If you work on Linux or Windows, SimpLESS will suit you better. I prefer LESS.app because it minifies CSS and has an interface that’s clearer if not prettier than SimpLESS.

When I begin a project I start with a LESSed up version 320 and Up that includes a compilation of functions, mixins and operations from:

Plus a few of my own. (I’ll include my LESS files in the next release of 320 and Up.) Here’s just two of my LESS behaviours.

.font-size(@font-size: 16){
@rem: (@font-size / 10);
font-size: @font-size * 1px;
font-size: ~"@{rem}rem"; }

Converts pixels to relative em (rem) units and includes a fallback for browsers that don’t understand rem. I just write:

h1 {
.font-size(32); }

LESS outputs:

h1 {
font-size:32px;
font-size:3.2rem; }

I often use tints of just one or two, sometimes complementary, colours per design. I’ve been doing for years. LESS makes working with my colour palettes even easier.

@col : #468DB6;			// Base colour
@comp : spin(@col, 180);  	// Complementary colour

@Col_l1 : lighten(@col, 5%);	// Lighten base
@Col_l2 : lighten(@col, 10%);
@Col_l3 : lighten(@col, 15%);
@Col_l4 : lighten(@col, 20%);

@Col_d1 : darken(@col, 5%);	// Darken base
@Col_d2 : darken(@col, 10%);
@Col_d3 : darken(@col, 15%);
@Col_d4 : darken(@col, 20%);

@Comp_l1 : lighten(@comp, 5%);	// Lighten complementary
@Comp_l2 : lighten(@comp, 10%);
@Comp_l3 : lighten(@comp, 15%);
@Comp_l4 : lighten(@comp, 20%);

@Comp_d1 : darken(@comp, 5%);	// Darken complementary
@Comp_d2 : darken(@comp, 10%);
@Comp_d3 : darken(@comp, 15%);
@Comp_d4 : darken(@comp, 20%);

LESS outputs:

.col1{background-color:#5799be;}
.col2{background-color:#6aa4c5;}
.col3{background-color:#7cafcd;}
.col4{background-color:#8ebad4;}
.col5{background-color:#3f7fa4;}
.col6{background-color:#387091;}
.col7{background-color:#31627f;}
.col8{background-color:#2a546c;}
.col9{background-color:#be7d57;}
.col10{background-color:#c58b6a;}
.col11{background-color:#cd997c;}
.col12{background-color:#d4a88e;}
.col13{background-color:#a4643f;}
.col14{background-color:#915938;}
.col15{background-color:#7f4d31;}

Now I can switch base colours and create new colour themes in a second or two. It makes designing in a browser so much faster that I can hardly imagine why anyone still uses Photoshop for this kind of thing.

Although I’ve not discovered my perfect set of responsive design LESS styles yet, these have come close.

It’s not all roses though. There are some LESS behaviours that I simply won’t use. Nested rules might look like time savers, but the time you’ll spend debugging specificity will soon use up any time you save.

While LESS is not particular about indentation and white-space, I am. When you work in a team — as I’ve been doing recently — unless you’re really careful about observing indentation and white-space conventions, nested rules will soon become almost impossible to follow. Nested rules promote bad practice too. The CSS they produce reeks of over specificity.

[role="banner"] {width:100%;}
[role="banner"] h1 {font-size:3.2rem;}
[role="banner"] h1 a {display:block;}
[role="banner"] h1 a span {opacity:0;}

This is clearly a case where your knowledge of what’s best should override using a tool.

Whenever someone talks about tools like LESS or Sass, the conversation can too easily turn to which tool is best. I’m not interested in that. What matters is that we find tools and workflows that work well for us. LESS works for me. In fact, it works so well for me, that I can’t imagine working on a project without it.

Like I said:

I once wrote that there was no need to use a CSS pre-processor like LESS or Sass. I was wrong. Very sorry.