Using LESS as a Live CSS Engine

Published by Guest Author

The following is a guest post by Andrew Powers of PageLines. Andrew wrote to me about how they use LESS in their product and how they think it's better than Sass for what they do. In complete honesty, I still disagree (they are using an unofficial PHP port of LESS, and there is an unofficial PHP port of Sass also), but I can't argue that they way they use it is pretty cool and works for them. This is Andrew explaining that.

There has been a lot of talk recently about using LESS/Sass as preprocessors for creating cleaner, cross-browser friendly CSS faster and easier than we could before. And from my own experience I can tell you that once you go to one of these languages, you’ll have so much fun that you won’t be going back to plain CSS.

The problem with these languages, however, is the word ‘preprocessor.’

The idea of a preprocessor is there is this ‘processing’ step between the code you write and the code you use on your site. That’s kind of a hassle. Also it prevents us from using variables or functions dynamically, which might be useful if you have users customizing the presentation of your code (like in a WordPress theme).

Well, live processing LESS in production is very possible, and here is how we’re using it to solve some big problems at our company.

About PageLines

pagelines-loves-less

PageLines makes a ‘drag and drop’ framework, built on WordPress, intended to make building professional websites easy.

Trying to keep the professional, yet easy (typical users shouldn’t have to write *any* code), has created a few engineering challenges which LESS has helped solve.

Use Case

The PageLines framework is built on WordPress (in PHP). In considering this solution we had several goals. For example, we wanted to:

  • Allow CSS to be customized based on user options inside the framework
  • Organize and compartmentalize CSS better without upping performance killing HTTP requests
  • Create better, more cross-browser designs, faster and easier without having to deal with a new ‘preprocessing’ step in our workflow

Why LESS for Live Processing? (Not SASS/Compass)

Chris wrote an interesting article on the merits of Sass vs. LESS. However, there are a couple thoughts left out that shift things in the favor of LESS for live processing for us. Specifically LESS was designed in JavaScript, the developer friendly language, and was also created to be used live. Most importantly, it compiles 6x faster than SASS. Jacob Thornton, architect of the popular Bootstrap by Twitter, has some more input on the debate here.

While the original live less.js approach has too much of a delay in production, it still helps seal the deal for LESS when we’re talking about using it in production instead of as a preprocessor. We ultimately used a special PHP port of Less.js to accomplish our goal, more on that in a second.

As a sidenote, it’s theoretically possible to use SASS ‘live’ if you’re developing in a Ruby on Rails environment. We haven’t actually tested this, so I’m not sure about the performance or bottlenecks using that approach.

How we implemented it

For us the the key to executing a live LESS engine was this port of the LESS processor to PHP (link) which allowed us to parse and cache LESS files based on user action on our server. To get this working the framework just does the following.

  • Grabs all the LESS files throughout the framework and adds them to a PHP variable
  • Uses the above PHP script to parse the LESS into CSS and puts it in a variable
  • Outputs the CSS to a file which is cached both on the server and on visitors browsers
  • The process is run again whenever a user saves their settings or installs a new extension

Code Example

This isn’t the actual code we used, but should give you a general idea.

$parser = new lessc(); // Start new object from PHP Less script
$less_code = file_get_contents(‘/path/to/whatever.less’); // Grab LESS
$processed_css = $parser->parse($less_code); // Process to CSS
file_put_contents(‘path/to/css-file.css’, $processed_css); // Write CSS
echo “<link rel='stylesheet' href='http://url/to/css-file.css' type='text/css' media='all' />”; // Link CSS in page

Results

dynamic-colors
Changing background color in the framework. Highlights and contrast element colors are calculated using LESS.

Control - Dynamic Colors and Typography

One of the coolest things about implementing LESS inside of the framework is that we’re able to dynamically control colors and typography based on user selections. This allows us to design things well, while still giving users the ability to customize colors and type.

Options - LESS Option for Users

lessoption

Users are able to actually add their own LESS in the admin options panel. They can use common variables for the background color or main fonts. This has been a feature that users love and can use to create more cross-browser, robust customization of the framework.

Organization - Several Files Into One

files-to-one

Using a processor for the LESS allows us to have all our css/less files organized by type, then grouped together at runtime into a single ‘compiled-css’ file. Definitely makes it easier to find what we’re looking for.

Optimization - Cleaner, Faster, Cross-Browser CSS

mixins

Because we can use nested selectors & mixins the code we are writing is much cleaner. While this is the same as when using a preprocessor, not having to deal with finding all the files and compiling allows us to use this without the hassles.