Many people will often ask, "If we're producing CSS, why aren't we just writing it instead?" It's a common reaction; after all, we use CSS every day to solve any layout problem thrown at us while building beautiful responsive sites that work in any browser. The last thing we want is to not look like we know what we're doing, right?

Let me be clear from the outset: the purpose of using Less is not to write better CSS. If you don't understand how to use CSS now, then Less won't help you fill that gap. What it will do is help you write CSS faster and more easily, while making your style sheets more manageable at the same time. Let's explore some of the reasons why we should switch to using a CSS preprocessor, such as Less, in more detail:

Now that we've explored some of the advantages of using a CSS preprocessor, let's delve in and get acquainted with Less for the first time. We'll go on a whistle-stop tour in order to give you a flavor of what to expect in Less. Don't worry if you don't understand it just yet; we will cover everything in more detail throughout the book.

How many times have you worked on a website where you needed to declare the value of a color in CSS, such as #ececec? 10 times? 20 times? It's rare that you will get the color in the first time; it is more likely that you will need to revise it, which can create a real burden when working in CSS. No matter how many times it ends up being, one thing is true: it is not easy to remember the hex value for each color.

Less can help by allowing us to define colors as variables, with more memorable names. A variable is merely a mechanism for referencing a value; take a look at the following three examples:

@red: #de1446; 
@blue: #4a14de; 
@green: #32de14;

The beauty of Less is that once we've defined these variables, Less will automatically update any instance where they are used if we decide to change the hex values at a later date.

.red-box {
  color: @red;
}

.red-box {
  color: #de1446
}

.serif() {
  font-family: Georgia, 'Times New Roman', serif;
}

p {
  font-size: 10px;
  line-height: 1.25em;
  .serif;
}

p {
  font-size: 10px;
  line-height: 1.25em;
  font-family: Georgia, 'Times New Roman', serif;
}

In more recent browsers, you are likely to find websites using RGBA (Red Green Blue Alpha) and HSLA (Hue Saturation Lightness Alpha) colors, rather than the typical hex values that we saw in the previous section.

Not every browser supports these color formats—to get around this, we can declare a hex value first, followed by its RGBA or HSL equivalents. As an example, we might write something similar to the following code in order to turn the text set with the h1 attribute to dark brown:

h1 {
  color: #963529;
  color: rgba(150, 53, 41, 0.5);
}

If we're choosing colors in a graphics package such as Photoshop or GIMP, we might occasionally struggle to get both the values and might need to resort to alternative means. Thankfully, this is not an issue with Less as it allows us to use functions to create new values automatically.

Why will we do this? The answer is simple: all we need to do is provide a color value using one format, such as RGBA. We can then use Less' functions to convert it to a different format—we can then avoid any confusion about ensuring we've provided the right values, as these will be worked out automatically by Less.

Let's take a look at a quick example of how this will work:

.brown-color {
  @rgbaColor: rgba(150, 53, 41, 0.5);

  color: fade(@rgbaColor, 100%);
  color: @rgbaColor;
}

Here, we've used a simple variable to define the base color before using the rgba color function to convert it to its RGBA equivalent value, with the alpha value set to 0.5. If we compile the Less code, it produces the following CSS:

.brown-color {
  color: #963529;
  color: rgba(150, 53, 41, 0.5);
}

The alpha channel in our example is set at 50 percent. This means that we can see 50 percent of whatever is behind the color in the browsers that understand RGBA. The use of functions will really come into their own when creating themes for sites—we could potentially create a whole host of colors from just two to three base colors!

We will explore more about the color functions later in this book, in Chapter 12, Color Processing with Less.

The beauty about using CSS3 is that there's no need to always use images, when we can often achieve the same result using pure styling alone. Trouble is, catering to all these new features, such as background gradients, animations, box shadows, and the like, means that we often have to use vendor prefixes or different syntaxes to ensure that the site can be viewed by the widest possible audience.

This can be a real pain but not so much with preprocessors. As you will see later in Chapter 4, Working with Variables, Mixins, and Functions, we can create a mixin or a small block of predefined code that can literally be mixed in our Less style sheet and can be used to create valid CSS. Take, for example, the following block of code, which is used to produce rounded corners:

.roundcorners { 
  -webkit-border-radius: 4px; 
  -moz-border-radius: 4px; 
  -ms-border-radius: 4px; 
  -o-border-radius: 4px; 
  border-radius: 4px; 
}

With Less, there are hundreds of mixins that are available online (more of which we will cover later in the book), which we can use in our code. Instead of having to remember what each style needs in terms of prefixes and syntax, we can just use the following code:

.roundedcorners {
  .border-radius;
}

The preceding code produces exactly the same CSS that was once compiled; Less automatically adds all the vendor prefixes, which is a great time saver.

The advent of mobile devices has created a need for responsive websites, which will display content only if the rules meet a specific environmental condition or breakpoint. A good example is determining the size of the screen in use when browsing a responsive website.

This normally means having to write a number of queries for each breakpoint in a design. As an example, we could write the following (simplified) CSS to change the typography for a particular device:

@media only screen and (max-width: 529px) {
  h1 {
    font-size: 0.7em;
  }
}

@media only screen and (max-width: 949px) {
  h1 {
    font-size: 0.9em;
  }
}

@media only screen and (max-width: 1128px) {
  h1 {
    font-size: 1.1em;
  }
}

Even though this is only setting the size for the h1 attribute, it seems like a lot to remember. We can simplify the code using the power of Less:

@smallwidth: ~"only screen and (max-width: 529px)";
@mediumwidth: ~"only screen and (max-width: 949px)";
@largewidth: ~"only screen and (max-width: 1128px)";

h1 {
    @media @smallwidth { font-size: 0.7em; }
    @media @mediumwidth { font-size: 0.9em; }
    @media @largewidth { font-size: 1.1em; }
}

We start by declaring three variables, each containing the media query statements. These are static values and will only change if we decide to add or modify any of the supported breakpoints. It isn't essential to use them in this instance, but it will help make the nesting solution easier to read!

We then call each media query using @media, followed by the variable that contains the breakpoint we wish to test against. The key point here is that while it might look like @media is repeated, we can't base our nesting style on @media as the code will fail to compile. Instead, we need to base it on the h1 selector for the code to compile correctly.

One of the limitations of CSS is that we often find ourselves applying the same values across multiple elements, throughout each site that we build. On a small site, this is less of an inconvenience, but for larger sites, there is a greater risk that we may miss updating a value, which could produce unexpected results. We've seen how you can reduce (or even eliminate, with good planning), the risk using variables—what if we could reuse our code in future projects?

This is not as crazy as it might seem—we may develop a specific drop-shadow style for buttons that we like and want to reuse. The conventional way is to store this in a text file, database, or the likes, and then dig it out each time we need to reuse it. It's a cumbersome way to do it, even if it does work—the need to do this is eliminated if we use a preprocessor.

We can simply store the code in a file, in the form of mixins or reusable blocks of code. If we need to reuse any of them, we simply add the file to our project and use the following command to import the contents:

@import "mixinfile.less";

The beauty of using Less though means that it will only import those mixins that are needed for our project in the main CSS file.

So far, we've talked about some of the compelling features of Less—a fraction of what it offers—there is a lot more that we will cover throughout the book as well as taking a look at some of the more practical uses of Less.

There is one key thing to writing CSS that we've not mentioned: the ability to compress your style sheets as part of releasing your site into production. Compressing our style sheets removes white space and allows us to concatenate multiple files in one master CSS file.

Why should you do this? The answer is easy: it will make style sheets a fraction of the size of the original, which saves on bandwidth. While this is probably less of an issue for normal Internet connections, it is critical for those using mobile devices with limited bandwidth.

How will you compress your CSS? Sure, we could compress it using an online tool, but this means using an extra tool, which adds to your already busy development. There is no need to do this when using Less—if you compile your code using one of the GUI tools, such as WinLess, or even the command line, you can set it to compress the code at the same time.

This is just a taste of what Less can offer. Before getting up and running the development tools we will need for using Less, let's take a brief look at what CSS4 will offer and how this might affect preprocessor tools such as Less.

Support for future CSS standards (or CSS4, as it is frequently termed) is still very much in its early stages within Less. Some progress has been made to allow the use of selectors in Less, which can be used with the ampersand symbol, as we saw earlier in the Supporting CSS4 standards within Less section in this chapter.

At the time of writing this book, the developers have refrained from adding too many new features for CSS4, as most of the current proposed changes are still in the draft state and are subject to change. The main feature added so far is that of support for attributes, which appeared in Version 1.4 of Less—others will appear once the specification has been finalized and support has appeared in more than one browser. The key thing to note though is that any CSS4 standard with CSS3 syntax is automatically supported in Less.

There will still be a need for Less once CSS4 standards become mainstream; Less will evolve to include the new standards while still allowing us to be more efficient when writing CSS.