A blog about code, management, Accessibility and the web in general

Main menu

Category Archives: CSS Less

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).

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.

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:

A site-area example

LESS

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

@color1:#096a10;

.site-area-1 {

a {

color:@color1;

&:visited {

color:darken(@color1,20%);

}

&:hover,

&:focus {

color:lighten(@color1,20%);

}

}

h2, h3 {color:@color1;}

h4, h5, h6 {color:lighten(@color1,10%);}

// ul

.sidemenu {

li {

a {

color:@color1;

&:hover,

&:focus {

background:@color1;

color:white;

}

}

}

}

}

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:

Deploying local variables

LESS

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

@color1:#096a10;

.site-area-1 {

@site-area-color:@color1;

a {

color:@site-area-color;

&:visited {

color:darken(@site-area-color,20%);

}

&:hover,

&:focus {

color:lighten(@site-area-color,20%);

}

}

h2, h3 {color:@site-area-color;}

h4, h5, h6 {color:lighten(@site-area-color,10%);}

// ul

.sidemenu {

li {

a {

color:@site-area-color;

&:hover,

&:focus {

background:@site-area-color;

color:white;

}

}

}

}

}

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.

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.

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.

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.

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 in Less

LESS

1

2

3

4

@nice-blue:#5B83AD;

@light-blue:@nice-blue+#111;

#header {color:@light-blue;}

Output

Variables output

LESS

1

#header {color:#6c94be;}

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

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:

Rounded corners mixin

LESS

1

2

3

4

5

6

7

8

9

.border-radius (@radius: 4px) {

-webkit-border-radius:@radius;

-moz-border-radius:@radius;

-o-border-radius:@radius;

border-radius:@radius;

-moz-background-clip:padding;

-webkit-background-clip:padding-box;

background-clip:padding-box;

}

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

LESS

1

.border-radius();

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.