As some of you may know I have recently been hard at work porting Less Css for .NET and I thought it was about time I actually gave my opinion on the syntax and offered a few of my thoughts on usage.

Variables

The first thing that strikes most people about the Less syntax is the use of variables. I have to say I still find this extremely useful, and its often overlooked that properties and variables are also accessible from within a nested ruleset scope i.e:

#defaults {
  @width: 960px;
}
.article { color: #294366; }
.comment {
  width: #defaults[@width];
  color: .article['color'];
}

Also variables are, well.. erm…  variable and they change their value depending on the scope that you find them in i.e:

@var: red;
#page {
  @var: white;
  #header {
    color: @var; // white
  }
}

The use of variables really requires a little bit of thought. Other than the “corporate colour” example it is often difficult to determine what candidates are eligible for variables. I have found this is a lot easier if I’m working against a design and I site down with a cup of tea first and plan out my approach.

The other issue I have is that I can never remember the names of the damn things. This may be a personal problem with my goldfish like memory span, but I certainly wouldn’t sniff at a bit of tooling support. Now as I type we are currently looking at visual studio integration, but with true MS spirit, they have made this bloody painful so don’t expect instant results.

Mixins

Other than variables, which are pretty cool we also get the advantage of mix-ins and operators at our fingertips. Mix-ins are great for creating reusable chunks of style info that we can easily “mix-in” to another element.

That said, this same functionality can be gained by adding several classes to a HTML element. One of the first pain point I had with Less was trying to justify using mix-ins, and for the most part I have to admit they are pretty funky, but equally useless.

One pitfall, for example is that it is often it’s common to use client side scripting to effect page layout by dynamically adding or remove the CSS classes on an element. Obviously, this is not possible if we have mixed several classes into one instead of adding them separately to them HTML node.

HOWEVER…

As with anything, when used correctly mix-ins are really valuable. Where mix-ins really shine, is when you couple them with a framework such as blueprint, and if any of you have used such frameworks things like this won’t be uncommon:

class="span-15 prepend-1 colborder"

With mixins we can bundle all these together and make a single class i.e:

@import "~/Content/blueprint/screen.css";
#sidebar{
    .span-15;
    .prepend-1;
    .colbord
}

One, other cool thing worth noting about mix-ins is that you can access them via namespaces i.e:

.outer{
    content:"ignore me";
    .inner{
        content:"mix me";
    }
}
#mixer{
    .outer > .inner;
}

This obviously gives a much finer grain of control than simply adding CSS classes to an HTML element.

Its also worth mentioning that mix-ins also hurt my brain when trying to remember what I called the damn things. Once again, tooling will help here and I really should get on with the visual studio integration (or at least prod Erik a bit as he’s currently looking at it).

Imports

Imports allow you to bring together several Less/Css files and merge them into one. You will even be able to access variables/properties from the file you import. Imports are great even if you don’t want to use any of the syntactical sugar that you get with Less and simply want a way to merge your CSS files together.

All in all I can’t get enough of imports as a way of separating my Less style sheets into manageable, reusable sections. There are however, a few gotchas you’ll have to keep in mid with Imports, and they are:

  • When caching is enabled in the Http Handler the cache will only be recycled if the main reference Less file is changed, and not any imported files.  This is no big deal, simply disable the HttpCache until you deploy.
  • Imports will not have access to variables in the main reference Less file (or other referenced Less files in the main one). This ensures that imported Less files have no dependencies on where they are been used.

Futures

As with any language/framework/whatever there are issues that you will hit, but all-in-all I really enjoy working with Less. I think we could expand on the tooling though and as I mentioned our first port of call is VS integration, but other than this here are a few other ideas we have thrown around:

  • Environmental and query string variables passed via the HttpHandler for use in our Less document.
  • Conditional (IF/THEN/ELSE) blocks – This combined with environmental variables would allow switching on say browser or maybe the currently selected theme held in the session.
  • Mix-ins with variables – this is actually implemented in the Ruby library, but we are yet to port it.

Any other thoughts and ideas welcome.