More Object Oriented CSS with LESS

I’m not going to debate about which CSS preprocessor is the best.

That’s up to you. Take your pick. SASS and LESS are both great. They both have awesome functionality. I have the most experience with LESS but I may move to SASS in the future.

The purpose of preprocessors is to abstract away the pieces that we write over and over again so we can focus on the parts that are important. CSS is a very straight forward, static language which is fine as is. There’s no need for it to gain variables and functions because preprocessors have provided that for us.

Breaking Old Habits

What I believe to be the more important question is this: How can we use these tools to write CSS in a more object oriented manner, to be extensible and modular like dynamic languages? In large sites with lots of changing pieces and multiple developers involved, CSS can very quickly become spaghetti with bits tied to other bits that conflict and have to be overridden.

Preprocessors also make it too easy to develop some really nasty habits, like nesting. Our natural tendency is to follow the DOM structure, like this:

.my-awesome-class {
  .this-thing {
    .gots-this-thing,
    .and-this-thing,
    .and-one-other-thing {
      .oh-and-this-thing {
        .color: #fff;
      }
    }
  }
}

Whenever I see this, well, to illustrate…

Goodman

What this just created was a ton of duplicated CSS. In addition, those styles aren’t accessible outside of this element. Try not to nest more than one level, and make a unique class for each unique element. If you have three common classes that you’re targeting inside of your base class, you can either make them one unique class or use one of the techniques I’m going to get into in a minute.

LESS has some extra functionality that can help address these problems. It’s still up to us to come up with better patterns and best practices in how to use them, and I haven’t quite mastered this yet myself, but I can at least share what I’ve learned so far.

Extend

Now here’s a super cool capability that LESS has (there is a SASS version as well). Say you have a core button style that you’re using throughout a project. You give it a class of .button and you start to have variations, like red-btn and big-btn. In the old days of CSS we would be duplicating these styles over and over. You could also stack several classes onto an element on the DOM, like:

<button class="button red-btn big-btn">

which makes a mess. Using LESS, you could simply copy those styles in like this:

.big-btn {
  .button;
  font-size: 18px;
}

But what that does is duplicate those styles from .button and drop them in there, bloating up your compiled CSS.

With :extend(), you can make .button your ‘prototype’ and when you get around to making your .big-btn, you’ll build it like this:

.big-btn:extend(.button) {
  font-size: 18px;
}

Instead of duplicating that CSS, it will render it like this:

.button,
.big-btn {
  // your rules
}
.big-btn {
  font-size: 18px;
}

This is much more like what we want. LESS is smart enough to group what’s common instead of duplicating those rules. Read more about this in their docs.

Namespaces

Name spacing is a concept from more advanced languages like JavaScript. Just like nesting variables inside other variables, you can create the same in LESS.

Say you have a bunch of block styles on your page. They have a few common base styles but you need them to each be unique. You can do this by setting up a namespace that holds mixins to render each of those styles:

#panels {
  .blue-panel() {
    // your rules
  }
  .red-panel() {
    // your rules
  }
}

Then you can pull one of these rules into your custom panel like this:

.custom-panel {
  #panels > .blue-panel();
}

Your namespaces won’t render in your CSS, only the output of the mixins you call. This way you can keep your boilerplate in one place and your rules are just a reference. You can read more about this in their docs.

The Takeaway

What I hope we can learn from this is there are tools built into both LESS and SASS that have enabled us to change our approach to writing CSS. We can take these tools and create efficient and reusable patterns that will keep projects more manageable, saving us time and (hopefully) our sanity.