When LESS is just enough

Published on

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.

She starts with the difficulty of debugging the compiled CSS:

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.

Yep, totally annoying and, as Allison suggests, never 100% avoidable. While I would argue that fundamental LESS features (such as variable and operator support) more than make up for time lost to this quirk, there are still a couple of ways to minimize its impact:

  1. Use @import in your primary style sheet to include your mixins and variables in one or more separate files. Since these will usually contain the majority of your un-compiled styles, the resultant CSS should map a little bit closer to your LESS line numbers.

  2. If you’re using less.js for development (as opposed to less.app or a server-side compiler), calling less.watch() appending #!watch to your URL and refreshing the page will make LESS asynchronously recompile whenever your style sheet is modified. This can greatly expedite troubleshooting, especially if you have enough screen real estate to develop and preview side-by-side.

Allison’s other concern is the risk of “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.

She provides a brief example of potential code bloat while suggesting that LESS users “are encouraged to embed [declarations] into each selector individually in the form of a mixin”. To be clear, this behavior isn’t encouraged by LESS any more than repetitious selections are encouraged by jQuery. If you use LESS to enhance your existing principles of well-formed and scalable CSS, there’s no reason why your code bloat should become unmanageable.

Example time! Let’s say we have an hCard with a photo, full name and role we’d like to style. Our vanilla CSS might look like this:

.vcard {
  border: 1px solid #ccc;
  margin: 10px;
  padding: 10px;
  -webkit-border-radius: 3px;
  -moz-border-radius: 3px;
  border-radius: 3px;
}
.vcard,
.vcard .photo {
  -webkit-box-shadow: 0 1px 3px #eee;
  -moz-box-shadow: 0 1px 3px #eee;
  box-shadow: 0 1px 3px #eee;
}
.vcard .photo {
  float: right;
  margin: 0 0 10px 10px;
}
.vcard .fn {
  font-weight: bold;
  text-transform: uppercase;
}
.vcard .role {
  color: #999;
  font-size: 87.5%; /* 14px / 16px */
}

Not unmanageable. But let’s see how we can make it easier to read, write and expand upon using LESS. We’ll start by looking for things that can be re-used or streamlined. The gutter value seems to be consistent, so we’ll move that to a variable so we can change it easily. Also, those vendor prefixes are a bit lengthy, so we’ll move them into mixins we can re-use anywhere.

@gutter: 10px;
.border-radius (@radius) {
  -webkit-border-radius: @radius;
  -moz-border-radius: @radius;
  border-radius: @radius;
}
.box-shadow (@shadow) {
  -webkit-box-shadow: @shadow;
  -moz-box-shadow: @shadow;
  box-shadow: @shadow;
}

With our variables and mixins established, we can rewrite our LESS like so:

.vcard {
  border: 1px solid #ccc;
  margin: @gutter;
  padding: @gutter;
  .border-radius(3px);
  &,
  .photo {
    .box-shadow(0 1px 3px #eee);
  }
  .photo {
    float: right;
    margin: 0 0 @gutter @gutter;
  }
  .fn {
    font-weight: bold;
    text-transform: uppercase;
  }
  .role {
    color: #999;
    font-size: 14 / 16 * 100%;
  }
}

Note the use of the ampersand combinator, which will be replaced with the parent selector (.vcard) in the output. Combined with the nested .photo, .fn and .role selectors, we’ve avoided re-typing the parent selector altogether. We’re no longer repeating vendor prefixes or margin/padding sizes, and LESS can do the font-size math for us. Best of all, the output is identical to that of our vanilla CSS. Sayonara, code bloat!

I’m not saying that Allison’s criticism isn’t a possibility in LESS… only that it’s a direct result of how you choose to use the language. In his blog post CSS: Taking control of the cascade, Jason Z. illustrates a LESS technique that he finds valuable in spite of its verbosity. LESS won’t make these decisions for you, it only provides the tools to do the job faster and easier than you could have otherwise.

To quote Stan Lee in Spider-Man’s first appearance, “with great power there must also come – great responsibility!”