Skip to main content

  • January 26, 2012

More or LESS?

I love writing CSS. I really do. I love spinning straw into gold, rescuing HTML elements from browser default styles, curving corners, softening colors, and cushioning containers. Decorative Illustration I love abstracting complex design systems into powerful classes and efficient declarations while minding the cascade and the rules of inheritance and specificity. I see a site’s visual design as one giant puzzle, patiently waiting to be analyzed, broken down into component parts, and built back up again. I easily spend 70% of my time at Happy Cog developing the presentation layer, so I’ve had my eye on the hot newness that is the Sass / LESS / CSS preprocessor movement for a little while now.

LESS and other CSS preprocessors are tools which, through the use of things like variables, mixins and operations, weave programmatic principals and logic into otherwise static CSS. Think of it as supercharged CSS. Recently, I had the opportunity to work with LESS professionally, since it was a requirement for a client project. Over the course of development, I found things to both love and loathe about LESS.

LESS is Less

Among developers, LESS is looked at as a tool for rapid development. I was told I should give it a try for an hour and I’d be hooked. Sure, I was able to learn the key concepts behind what makes LESS special in about an hour. As I dug deeper and actually applied those concepts to my style sheets and essentially restructured the way I’ve grown accustomed to writing CSS over the years, it proved to be a bit more time-intensive.

It’s fair to chalk some of my gripes up to inexperience. As I was getting started writing LESS, I’ll admit I struggled to recall the appropriate variables and mixins on the fly. Surely, if I wrote LESS all day every day, I would have had my conventions nailed down and this would no longer be an issue. No, my major issue with LESS, the one which I feel most dramatically negated the time-savings benefit to me, was debugging.

LESS, by virtue of the compiler, rewrites and reformats CSS, which means the line numbers referenced by Web Inspector or Firebug are guaranteed to be wrong. I found myself having to search for styles a lot more, whereas in the past I would have simply referenced the line number in the debugger. While this may seem like a small annoyance to many, it slowed me down quite a bit.

And my last point of contention with LESS: code bloat. Let’s face it, CSS is not exactly a champion of the DRY’t_repeat_yourself (Don’t Repeat Yourself) programming principal. Repetitious values in a pure CSS style sheet are the mark of a solid design system. Even the most well-written, pure CSS is typically teeming with identical declarations repeated over and over. I like that LESS advocates a very DRY approach to writing styles with shortcuts like mixins. And while the DRY approach is promoted inside the LESS files themselves, the generated CSS is anything but DRY. In fact, it’s far less DRY than pure CSS. Take image replacement, for example. In pure CSS, I would write an image replacement declaration once and add selectors to it as necessary.

h1 a, .pagination em, .cog a { display: block; text-indent: -9999em; background-color: transparent; background-position: 0 0; background-repeat: no-repeat; overflow: hidden; }

With LESS, we are encouraged to embed the declaration into each selector individually in the form of a mixin which then renders out to:

h1 a { display: block; text-indent: -9999em; background-color: transparent; background-position: 0 0; background-repeat: no-repeat; overflow: hidden; }
.pagination em { display: block; text-indent: -9999em; background-color: transparent; background-position: 0 0; background-repeat: no-repeat; overflow: hidden; }
.cog a { display: block; text-indent: -9999em; background-color: transparent; background-position: 0 0; background-repeat: no-repeat; overflow: hidden; }

Yikes. Not exactly DRY.

LESS is More

I know I’ve come down hard on LESS thus far, but I promise you, it wasn’t all bad. I found using LESS definitely had some fantastic benefits. For instance, I loved being able to use variables and simply write color: @green; instead of color: #6fcd58; and mixing in .border-double instead of writing

border-bottom: 2px solid #f8f8f8; padding-bottom: 11px; margin-bottom: 22px;

inside each appropriate declaration.

But even more than those small victories, I love how LESS forced me to focus on how I build both the horizontal and vertical grids. Assigning variables up front, which are then woven throughout each LESS file, promotes a very systematic approach and is, far and away, the best feature I found.

Take the vertical grid, for example. Our designs used a baseline of 11px. In order to maintain a vertical rhythm, I set up these variables:

@baseline: 11px;
@unit-xsmall: @baseline/2;
@unit-small: @baseline;
@unit-medium: @baseline*2;
@unit-large: @baseline*3;

Which I then wove into my style sheets like so:

h2 { font-size: @unit-large; margin-bottom: @unit-large; }
h3 { font-size: @unit-medium; margin-bottom: @unit-medium; }

Variables like these help keep me honest when writing styles.

The horizontal grid was even more fun to work with using LESS.
Our grid had 54px wide columns and 30px wide gutters.

I set these values up to be variables:

@grid-col: 54px;
@grid-gutter: 30px;

Then set up a function to pass parameters through:

.grid-width (theColumn: 1, @theGutter: 0) 
 { width: (grid-col * theColumn) + (grid-gutter * @theGutter); }

So, in Photoshop, all I’ll need to do is count the grid columns and gutters and punch them into .grid-width inside my LESS file like so

.sub { .grid-width(4,3); }

LESS then does the math for me, compiling this into the CSS which actually renders in the browser:

.sub { width: 306px }

This hardworking little parametric mixin definitely saved me a lot of time. Fumbling to write in widths quickly became a hurdle of the past.

I’ll admit I’m still wrestling with the pros and cons of LESS. The jury is out for me on whether or not LESS will make it into my preferred workflow moving forward. Either way, working with a CSS preprocessor was both a fun challenge and an eye-opening experience that I’m glad I dove into. I’m looking to try Sass on for size in the near future and compare the two in an upcoming article.

Let me know your thoughts about LESS. What do you like? What can’t you stand?

Back to Top