As simple as possible, as complex as necessary

The simplicity of LESS CSS with CfStatic

4 January 2012

It's that point in the calendar when we developers tend to reflect on technologies learned in the preceding 12 months and those we'd like to engage with in the year ahead.

My "tech-to-get-to-grips-with" list is too embarrassing to discuss, but there's one I'm pleased to have crossed off it recently and which I would commend to any CF dev looking for an easy-to-learn skill with a disproportionately large pay-off.

LESS is more

Any development tool called "Less" is likely to be attractive to a simplicity zealot like me (although less of anything doesn't guarantee it will be simpler) and when I came across LESS CSS on Nathan Strutz's excellent blog, among other places, the promise of bringing order at last to the chaos which Cascading Stylesheets can so easily become was irresistible.

As a programmer LESS lets you do with CSS what you're used to doing with code: write once and re-use without copying and pasting, and then change without search and replace.

For designers with zero programming experience there may be a small learning curve, but for developers the concepts are basic and the syntax can be grasped in a matter of minutes. Here's a quick example:

// Define a re-usable rule - yes, you can use // for comments in LESS CSS!
.rounded-corners( @radius ){
	-moz-border-radius: @radius;
	-webkit-border-radius: @radius;
	border-radius: @radius;
// invoke the rule for a selector and pass a parameter
	.rounded-corners( 10px );

This will be compiled to the following CSS:

	-moz-border-radius: 10px;
	-webkit-border-radius: 10px;
	border-radius: 10px;

Compilation issues

The reason I didn't dive straight in however was the implementation. Originally exclusive to Ruby, the compiler which turns the LESS syntax into regular browser-understandable CSS has been ported to client-side Javascript, meaning you don't need any particular server-side set-up. But it also means requiring all visitors to have a modern browser with Javascript turned on, as well as incurring a small overhead of client-side processing.

This was a deal-breaker. I'm all for progressive enhancement, but basic CSS should work for 100% of visitors, regardless of JS support.

CfStatic to the rescue

On to the back-burner it went, but not for long thanks to the ingenuity of Dominic Watson, whose magnificent CfStatic tool almost incidentally provides the key to using server-side LESS with ColdFusion. (See my earlier post on CfStatic to find out what its main job is.)

Wrapped inside CfStatic is a third-party LESS compiler written as a java library, which ColdFusion can run with a little help from JavaLoader (also rolled into CfStatic). All you need to do is replace your .css files with .less files, inside which you are free to use the new liberating syntax.

Screenshot of .less files in assets/css folder

CfStatic will then detect and compile the .less files to normal .css files with the same names and then use those as it continues minifying and concatenating.

Screenshot of .less files and compiled .css files in assets/css folder

Depending on your settings, CfStatic will check your .less files for changes and re-compile as required, but this only happens once on the server: the browser gets a normal .css file with no JS processing needed.

Things to watch out for

One or two things have tripped me up as I've been getting used to this new way of doing Stylesheets:

  • Be careful with the semi-colons at the end of each rule. There must be one and only one or the compiler will complain.
  • Avoid tabs in selectors. Tabs will be stripped completely: eg. #id[TAB]element will become #idelement. Use spaces instead: #id[SPACE]element to produce #id element.

Writing LESS CSS is a joy compared to what we might now call "raw" CSS, although I'm still feeling my way around how best to structure it for optimal re-use given the new freedoms.


  • Formatting comments: See this list of formatting tags you can use in your comments.
  • Want to paste code? Enclose within <pre><code> tags for syntax higlighting and better formatting and if possible use script. If your code includes "self-closing" tags, such as <cfargument>, you must add an explicit closing tag, otherwise it is likely to be mangled by the Disqus parser.
Back to the top