CSS and LESS Introduction, Tutorial & Guide

If we've worked with style sheets within the last few years, there's no chance we won't have heard of LESS; however, for the sake of those who didn't, let's take a few words to talk about it.

Before getting to that, though, we must briefly introduce the concepts of style sheet language and Cascading Style Sheets (CSS).

DISCLAIMER: The first part of this article is mostly aimed at those who knows little about Cascading Style-Sheets. If you have some experience with CSS already or feel like you don't need to know anything else about why we're going to use it, you might as well skip it entirely and jump to the What is LESS and why to use it paragraph.

Style sheet languages

A style sheet language, also known as style language, is a programming language used to define the presentation layer's UI design rules of a structured document. We can think of it as a skin or a theme that we can apply to a logical item (the structured document) to change its appearance. For example, we can make it look blue, red, or yellow; we can make the characters bigger or smaller, thinner, or wider; we can change the text spacing, alignment, and flow; and so on.

Using dedicated style sheet languages gives developers the chance to separate the presentation layer's code and structure (respectively JavaScript and HTML) from the UI design rules, thus enforcing the separation of concerns (SoC) principle within the presentation layer itself.

When it comes to web pages, web applications, and anything else that mostly uses HTML, XHTML, XML, and other markup language-based documents, the most important style sheet language undoubtedly is CSS.

CSS

It was December 17, 1996, when the World Wide Web Consortium (W3C) released the official W3C CSS Recommendation for the style sheet language that would be known as CSS1. CSS2 came less than two years later (May 1998), while its revised version, CSS2.1, took considerably more time (June 2011).

Starting from CSS3, things started to become more complex, since the W3C ditched the single, monolithic specification approach by splitting it into separate documents called modules, each one of them following its very own publishing, acceptance, and recommendation history. Starting in 2012, with four of these (Media Queries, Namespaces, Selectors, and Color) being published as formal recommendations and full CSS2.1 backward-compatibility, CSS3 quickly became the most adopted style sheet language standard for the development of new websites.

CSS code sample

Luckily enough, the new features that were added to the CSS standard during the various versions (1, 2, 2.1, 3, 3.1 and so on) mantained a full backward compatibility with the previous one(s). For this very reason, regardless of its version, we're still dealing with the following syntax:

Which translates as follows:

The above CSS rule basically says that any HTML element with the quiz CSS class assigned will  have a light-grey background color, a black, solid, and pixel-wide border, no margin against the surrounding elements, and a certain amount of padding between its borders and the content.

To assign a CSS class to an HTML element, use the  class attribute in the following way:

If the attribute already exists, additional CSS classes can be assigned by separating them with a single space:

Simple enough, isn't it?

What is LESS and why to use it

LESS is a cascading style sheet pre-processor; we can think of it as a server-side script for CSS files, enabling us to do a number of things that CSS doesn't support (yet), just like PHP and/or ASP can do for an HTML page. The following diagram should help us to better understand the concept:

These are the main advantages of using a hypertext pre-processor instead of writing raw HTML pages; we're talking about PHP, but the same goes for ASP.NET Web Forms, Razor, and basically everything else.

The following are the advantages of using LESS instead of writing raw CSS files:

As we can see, they serve the exact same purpose in terms of assisting, improving, and enhancing the development effort.

Making the switch from static style sheets to dynamic style sheets is just as easy as switching from static HTML pages to PHP or ASP dynamic pages; they both feature a nested meta-language that can extend the base static language in a pure backward-compatible fashion. This means that a valid CSS file is also a valid LESS file, just as a valid HTML file is also a valid PHP or ASP file.

There are also some key differences between hypertext pre-processors and style sheet pre-processors, the most important being how web servers deal with them. Hypertext pre-processors such as PHP and ASP are compiled by the Web Server upon each request; the Web Server compiles them on the fly and then serves the resulting HTML for each request-response flow. Conversely, style sheet pre-processor files are usually compiled into standard CSS files before being published; in other words, the web service doesn't know about the existence of these files, as it just serves the resulting CSS-compiled result.

This also means that using a style sheet pre-processor will have no performance impact on the server, unless we choose to install some experimental and still highly inefficient handlers, extensions, modules, or client-side scripts that will compile the source files on the fly.

IMPORTANT NOTE: From now on, we'll take for granted that the reader has a decent knowledge of CSS files, syntax, selectors, and their common use within HTML pages. If this is not the case, we strongly suggest to learn the core CSS concepts before going further, using the Learning CSS website, maintained, and hosted by W3C, featuring a massive number of useful guides, tutorials, and articles:

• https://www.w3.org/Style/CSS/learning

Variables

Among the most valuable LESS features, there is variable support. This is a brief example of what we can do with it:

As we might have noticed, double-slash style (//) inline comments are supported as well, while CSS only allows the slash-asterisk (/**/) syntax.

Import directives

Another LESS key feature is the capability of importing other CSS and LESS files. If we're familiar with the standard CSS @import, we know that it can only be used at the beginning of the file to issue the loading of an external CSS file. With LESS, we can do the following:

Notice that the behavior depends on the imported file extension. These defaults can be overridden with the following options switches:

If we need to specify multiple options within a single @import statement, we can do that by separating each one of them with a comma:

Nested selectors

We will be able to nest selectors within other selectors, thus making our code more succinct and readable. Just to use a quick example, we can shrink this:

Into something like the following:

It might not be such a big deal for small-scale CSS files, yet we can see how it would definitely be a major readability improvement for large files.

Mixins

Being able to not repeat ourselves is a key principle of all computer programming languages; however, it's not easy to respect that within standard CSS files, because we would often be forced to write something like this:

With LESS, we can shrink it into this:

In other words, a mixin is a selector reference within another selector. That's another great feature that can save us a lot of time whenever we're dealing with large CSS files.

Extend pseudo-class

Another great feature is the LESS :extend pseudo-class, which can be used to apply all properties of a class to another class, optionally including, using the all keyword, all the child classes and pseudo-classes. To use a quick example, take the following CSS code:

This could be conveniently written this way using LESS:

Notice how, since we've used the all keyword, we don't have to repeat the :before pseudo-class of the base .link selector, as it will be applied to .link-red as well.

LESS docs and support

We won't go any further than that with LESS, as it would take us far from the scope of this book. From now on, we'll take for granted that everything that we're going to do with it will be acknowledged and understood.

For the sake of simplicity, we won't use anything different from what we briefly introduced in the previous chapters; however, we strongly suggest to take a look at the advanced features (parametric mixins, functions, loops, guards, and more) as soon as we have the chance; they can hardly fail to pay off. We can learn more about them from the LESS official webpage at the following URL:

• http://lesscss.org/

SASS, Stylus, and other alternatives

As most readers probably know, or can easily imagine, LESS is not the only style sheet pre-processor language out there. As a matter of fact, it was released more than two years after Systematically Awesome Style Sheets (Sass), also known as SCSS, which had served the exact same purpose since 2007. Sass can offer basically the same set of features as LESS and came out first, so why shouldn't it be used instead?

Truth to be told, no one will ever get fired for picking SASS or other viable alternatives, such as Stylus and Switch CSS, instead of LESS - expecially these days, since the LESS community isn't growing as much as their competitors users bases. As a matter of fact, if we consider the fact that even the insanely popular Boostrap framework ditched LESS in favor of SASS for its latest (v4) release, we could even say that SASS/SCSS will most likely be a better alternative - at least in 2018. The SASS community is also undisputably larger and more active than LESS, as the following chart clearly shows:

(source: Google Trends)

Truth to be told, there are many good reasons that could explain why the trend is going like this:

• Sass has a larger community.
• Sass lets the developer to write re-usable methods and use logic statements, such as conditionals and loops: although LESS can also do that (as we explained before) the syntax is somewhat counter-intuitive (ie. guarded mixins for conditionals,  self-referencing recursion for loops).
• Sass users can make use of the Compass library, a wonderful open-source CSS Authoring Framework. Although LESS can benefit of similar libraries, nothing really comes close to Compass, which is regularly maintained and contributed to by a  huge community. Compass has some invaluable features like dynamic sprite-map generation, legacy browser hacks, and cross-browser support for CSS3 features. Among its many features, Compass can also be leveraged with other external client-side frameworks like Blueprint, Foundation, or Bootstrap - which is arguably one of the main reasons why Bootstrap 4 switched to Sass as well.

Regardless of the above facts, we're free to choose the style sheet pre-processor we like the most, as long as we can use it without issues, meaning that our development framework - Visual Studio, for example - is able to support it. Luckily enough, all of them are now widely supported by many Visual Studio Extensions, so it won't make any significant difference.

Here's a list of some of the best extension tools that will provide support for LESS, Sass and/or other pre-processors:

• Web Compiler by Mads Kristensen, an all-around tool to compile LESS, Sass, Stylus, JSX and CoffeeScript directly within the Visual Studio Solution Explorer (right-click | Web Compiler | Compile File).
• LESS Compiler by Mads Kristensen, a lightweight alternative to the above which uses the official Node.js-based LESS compiler with no setup. Once installed, it will show a neat overlay in the lower-right corner of any LESS file opened with Visual Studio giving the developer the chance to turn the compile feature ON or OFF for the whole project and/or for the current file only; it doesn't support Sass.
• CompileSass by Sam Rueby, another lightweight alternative that looks for all files with the .scss extension and compile them in background using LibSass, resulting in fast compile times; it doesn't support LESS.

Any of these tools will do, as long as it supports the standard we want to use.

Print Friendly & PDF Download