What I Wish I Had Known When I Graduated College
Better Stakeholder Interviews
Ready. Launch. Update!
Take a Break!
Cognition
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. 
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 (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?
28 Responses
Used LESS in your development projects yet? @alliwagner shares her experience (the good and the bad) in Cognition: http://t.co/2ZekPEPf #fb
Thu, January 26, 2012 11:48:05
LESS is less, use Sass and @ extend to keep your compiled CSS DRY. Keeps file size way down yet maintainable.
Thu, January 26, 2012 12:00:06
Exactly: "..while the DRY approach is promoted inside the LESS files themselves, the generated CSS is anything but DRY"
Thu, January 26, 2012 12:12:30
Curious about #css preprocessors like Sass and LESS? Check out this review of LESS from my colleague @alliwagner.
Thu, January 26, 2012 12:25:32
TOTES another CSS tutorial on the internetzzz
Thu, January 26, 2012 12:45:55
It's easy to fall into bloated CSS with LESS, but if you can follow some good practices and not get lazy it's all good. http://t.co/ae26VEwR
Thu, January 26, 2012 1:03:13
Seems an honest assessment of CSS preprocessors. Re: image replacement, though, I’d just us a class & apply as needed. http://t.co/Te5zPPly
Thu, January 26, 2012 1:09:52
I think the key is to weigh the value of development time vs. the overhead on the client end. Depends on the project. http://t.co/odlhGNFN
Thu, January 26, 2012 1:18:07
I've found that using Codekit (http://incident57.com/codekit/) makes compiling & debugging LESS a breeze.
Thu, January 26, 2012 1:33:14
I feel the same about the neg. points. I've only thought to use it with is Sencha. What else can I use it with?
Thu, January 26, 2012 1:46:31
@jakefolio @erikvorhes Next time I'll keep mixins to 3 properties max and keep image replacement a global combination
Thu, January 26, 2012 1:52:40
A solid roundup on CSS pre-processors. Variables, mixins and compression are all I want form them. http://t.co/RbZtfWIy http://t.co/RbZtfWIy
Thu, January 26, 2012 2:20:40
LESS offers a lot, but it’s not perfect. @alliwagner's cognition review has me wanting to take it for a spin.
Thu, January 26, 2012 2:43:37
The holy grail you are looking for is @extend, feature of awesome in Sass.
Thu, January 26, 2012 9:24:23
More or LESS? http://t.co/kCKR60AR #css
Fri, January 27, 2012 5:26:22
LESS can generate a DRY output, if used wisely with that intent (and keeping http://smacss.com/ in mind)
Fri, January 27, 2012 5:32:23
One of the best blogs out there. Always get so much out of your posts. Thank you!
Fri, January 27, 2012 11:38:24
I use LESS lots & it's a perfect partner in making responsive sites-lets me start w/pixels & convert to % automatically
Fri, January 27, 2012 11:07:04
I would much rather go with something like SCSS. Way less bloated!
Sat, January 28, 2012 4:20:56
Fantastically balanced review of LESS stirring a real conversation, you owe it to yourself to read @alliwagner's post. http://t.co/SuCDN8y5
Sat, January 28, 2012 2:20:52
Really nice write-up by @alliwagner on LESS, much of which is easily applied to other CSS preprocessors as well.
Sat, January 28, 2012 2:31:56
Allison Wagner wrote a thoughtful post summarizing her experience with LESS on Happy Cog‘s lovely blog, Cognition. Her criticisms echoed my own when I first started using the self-described “dynamic stylesheet language,” so I thought I’d respond to them here so that other designer/developers might avoid similar points of trepidation. More →
Sat, January 28, 2012 5:36:06
If you're willing to sacrifice firebug debugging in exchange for mixins & variables, I absolutely recommend LESS.
Mon, January 30, 2012 10:27:32
More or LESS? http://t.co/jZVG1o6P
Sun, March 11, 2012 5:39:15
http://t.co/tbvG4kzE @alliwagner I'm using the LESS.app and I'm not getting the code bloat you described?
Mon, March 19, 2012 9:03:14
http://t.co/tbvG4kzE @alliwagner I just compiled your example with mixin using LESS.app and I'm not seeing the code bloat you described?
Mon, March 19, 2012 9:10:19
more of LESS http://t.co/qEZCH7ez couldn't have said it better myself. really.
Wed, August 22, 2012 2:46:37
Say no to code bloat, use Sass Silent Placeholders w/extends https://speakerdeck.com/anotheruiguy/sass-32-silent-classes
Wed, December 19, 2012 11:38:19