Two years ago, I tried to implement our web software interface using flexbox. Unfortunately, I was a little too eager in this endeavour, and had to hastily reinforce my fallbacks as the specification changed.

The Flexible Box Layout Model—commonly known as flexbox—has the potential to solve a number of perennial problems that front-end devs have been banging their heads against ever since CSS was invented in 1996, including equal height columns, true proportional width flexibility, and DOM ordering over-rides (very useful for Accessibility).

A number of these practical problems—and how flexbox solves them—are illustrated on Philip Walton’s Solved by Flexbox GitHub page.

However, as I discovered back in 2011, flexbox has had rather a chequered history—passing through three distinct specifications. Detailed support is outlined at caniuse.com, but, roughly, browser support is:

  • flexbox-legacy: supported by Safari 5–6 and Chrome 4–20;
  • flexbox-intermediate: Internet Explorer 10;
  • flexbox: Chrome 21+, Safari 6.1+ (allegedly), Firefox 21+ (sort of: there’s no support for flex-wrap and flex-flow).

To make things more complicated, Modernizr only has feature-detection for the oldest and newest syntax, which are output as flexbox-legacy and flexbox respectively.

And finally, once you delve into all of the possible variables, the syntax is not at all simple.

Luckily for us, a number of very smart people have been keeping up to date with all of the progress and built some useful web tools to generate code for us.

  • Flexyboxes provides a neat WYSIWYG interface for building flexible layouts, and it will generate code for all three syntaxes if you need to. Do be careful, however, as the older versions are not as capable as the up-to-date flexbox.
  • You can only use Flexplorer if your browser supports the latest syntax (which Safari 6.0.2 does not!), but it does also give a useful rundown of browser support for vendor prefix requirements.

With everything settling down—and a UI refresh of our software on the cards—I have been considering writing a set of LESS mixins for deploying flexbox in the wild. Inevitably, of course, putting “flexbox less mixins” swiftly shows that yet more smart people have got there first.

With so many to choose from, David de Coninck’s version jumped out at me most immediately—his use of guard expressions is really elegant.

See the Pen Flexbox 2013 LESS mixins by David De Coninck (@davidgenetic) on CodePen

Do you have a favourite LESS mixin that supports all of the syntaxes out of the box? Let me know in the comments…


Using local colour variables in Less

One of the most time-consuming aspects of website design is when the customer wants multi-coloured menus—and for those colours to cascade through the other attributes on those site areas. This can involve lots of different selectors, and having to change them all to different colours can be a pain—and this is where using local colour variables in Less can save lots of time.

Standard colour variables

Consider the following set of declarations:

Now, imagine that these all had to be altered depending on the .site-area-x, and that we have huge number of selectors to restyle.

Obviously, we could simply declare our @color2, but then we have to go through and change the colour in all of the other declarations too.

And this needs to be done for each one of the eight different menu areas—it’s going to be pretty time-consuming.

Local colour variables to the rescue

There is a better way in which to do this—by using local colour variables. Consider the following set of declarations:

We now only have to change two attributes—the .site-area-x class, and the @site-area-colour.

OK, it’s not entirely automated, but it will take considerably less time than the first method.

Using Less as a live CSS engine

Following on from my last post on CSS pre-processors, there is an interesting guest post over at CSS Tricks—from Andrew Powers of PageLineson using Less as a live CSS engine.

It seems that PageLines—who craft WordPress Templates—actually use Less as a live CSS engine for enabling customers to change settings in their templates.

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

This is extremely interesting because, ever since I started using Less, I have been contemplating using it for precisely the same thing within our company’s CMS.

Right now, our CMS uses a very advanced Dynamic Templating System (DTS) which reconfigures the page depending on what the user has placed on it, i.e. if you place a widget in the left-hand column, then it will generate a left-hand column; if you don’t, it won’t.

However, currently, all of the aesthetic styling has to be done by our own implementers; however, with the advent of multi-site functionality in our CMS, we are seeing an increased demand for advanced users to be able to make changes themselves.

Although we have implemented a system where aesthetics can be saved as Custom Style Presets—which can then be applied by the user—we have to write those presets first.

Ideally, we would actually allow the user to change certain colours themselves—but that leads to all sorts of complications that, in the end, would constrain our designers and deliver only partial control to the user.

Using Less as a live CSS engine is the way to get around this problem. However, since our system is not written in PHP, we would need to see if Less has been ported to ColdFusion (unlikely) or write the plugin ourselves (not currently a priority).

Whichever way we go with this, it is nevertheless great to see that there is an operating version of this concept being deployed in the wild.

CSS pre-processors

I discovered CSS Less about eighteen months ago (although I forget how) and began using it almost immediately: the power and flexibility of CSS pre-processors over the standard CSS language are immediate winners.

The real problem with CSS is that it is, by its very nature, a static language: it isn’t compiled by the browser—which makes rendering very fast, but limits the possibility for time-saving features such as variables.

And although the CSS Working Group have released a Draft Specification for CSS Variables (and WebKit has implemented it), the syntax is pretty clumsy to say the least.

So, for an increasing number of front-end developers, using a CSS pre-processor is becoming incredibly important. There are two main languages to choose from—the aforementioned Less, and Sass—but both share some common traits.

Both were written as Ruby Gems, both introduce time-saving concepts—such as variables and mixins—in syntactical extensions of CSS, and both feature compiling engine that “watch” your files, compiling them to CSS on save.

The mighty Chris Coyier wrote an article comparing both engines in which he came down firmly on the side of Sass: looking at his arguments, and code that I have seen in the wild (on CodePen, for instance) I accept that, logically, Chris is probably right.

However, for me, Less is the better language, and there are a few reasons for this:

  • although it originally started as a Ruby Gem, it wasn’t long before it had been ported to Javascript. Whilst JS is not my forte, it does mean that you can deploy Less on a live site (or, rather, during development): my colleagues and I deployed this method when lots of us were simultaneously implementing a site during 2011’s GiveCamp;
  • when I started investigating pre-processors, the talented Brian Jones had written a free Less compiler app for Mac OS X which meant that I didn’t have to muck about with the Terminal to get things set up. I now use his invaluable CodeKit application for all my compiling needs (although it does much more than just compile, e.g. image compression);
  • the Less syntax feels more CSS-like to me. As someone who is both very busy and entirely self-taught—as well as not being a natural “process” coder, this is an important point. It makes Less very quick for me to write, and to take advantage of the power of it very easily. (And I am only just tentatively scratching the surface of Less’s more powerful—and more code-like—features, such as Guard Expressions.)

Ultimately, it is entirely up to you which pre-processor you feel most comfortable with: but if you do any CSS work, you should definitely be using one of them. Here are just a few examples of the power that CSS Less gives you:

Variables (with colour operations)


Variables are worth the price of admission on their own, especially when combined with colour functions such as lighten, darken and fadeout.

We have saved substantial amount of time in implementing sites on our CMS simply by looking at all of the colours that are used in the front-end templates, and driving them off a few basic colour variables (which are dictated by the customer’s brand guidelines).


Mixins allow you to group together lots of properties for re-use. The single most useful deployment of mixins is for taking the tedium out of vendor prefixes—rounded corners, for instance:

As you can see, the above mixin will output all of the various vendor-prefixed variables: all I have to write is:

As you can imagine, just those two abilities have saved me huge amounts of time in building websites—and in maintaining them.

Many articles have been written about the power of pre-processors, so I am not going to recreate the user guide here: however, I shall be posting novel or useful Less snippets from time to time.