Top tips for mixin LESS and Sitecore – Part 1

1st January 2012

Lessons learnt from using LESS on our Sitecore websites

Having adopted LESS (a CSS extension) into our Sitecore front end development process a fair time ago, now seems as good a time as any for a review. This mini blog series will be reflection on the impact of LESS to our workflow, cover some approaches that we have taken and note some of the benefits gained/lessons learnt along the way. Also, it’ll hopefully raise some questions for debate and I’d really welcome your thoughts and any experiences that you’d be willing to share.

LESS mixin’ with Sitecore – part 1: LESS is more

I’ve always loved CSS… the basic concept of separating concerns (the presentation from content)… just how easy it is to visually change the appearance of well defined structured content. But as a programmer, CSS as a language has always seemed rudimentary and limiting in it’s authoring capabilities. It comes naturally, the desire to want to avoid replication, re-use code, make easy to read and understand. This is where LESS comes in… with familiar features such as import, variables, loops and functions, it has delivered the ability to streamline our workflow.

LESS colour doesn’t mean less colourful

At the very simplest level, the ability to define variables for a site’s colour palette is great and a real time saver. No more hex values taking up valuable space in your memory, simply replace your references to a hex value #bfe4e4 with the much more memorable @green. We’ve gone for the approach of defining all colours as variables in a separate LESS file. This separation can be useful for highlighting visual design colour discrepancies, ensuring colour consistencies, and perhaps convincing a designer they’ve used too many colours!

At this point in time we’ve stuck to naming the variables based on colour (e.g. @dark-green), however, an alternative approach might be to use general terms that might match branding guidelines (for example @primary2). This could potentially lead to an effective approach to the skinning or theming of sites/microsites.

LESS markup and LESS adjectives

We’ve found with the introduction of LESS our HTML markup is cleaner and rightly so, classes don’t describe how an element should appear. Gone are the days where an approach might be to add multiple CSS classes to HTML markup in an attempt to gain some kind of modular re-use. Instead, the handling of these patterns can all be done in LESS. An, example (if a little extreme):


<div class=”latest-news widget boxed rounded-corners float-right”>

<h2>Latest News</h2>….

Using Less:

<div class=”latest-news”>

<h2>Latest News</h2>….

.and then apply as LESS mixins







Take the same example above where the latest news widget no longer should have rounded corners. That would have previously required a change to the markup. Now the presentation of the latest-news widget can (within reason) all be done using LESS.

LESS but more

On the flip side, the approach above is a perfect example of one of the negative sides of LESS… CSS Bloating. Mixins essentially create duplicate rules/code within different selectors where modular would only mean the rules exist once. In addition to that, LESS doesn’t to me seem to gracefully handle multiple selectors.. again creating bloated CSS.

Take the following combined example:

.latest-news, .latest-blog, .latest-events{




border: 1px solid blue;

background-color: grey;

padding: 1em;


This would create three separate selectors  with the same duplicate rules.