Posts Tagged ‘CSS’

CSS pre-processors part two: Mixins and nesting

Published by | Monday, August 27th, 2012

In my last article, An Introduction to LESS and Sass pre-processed CSS languages, I wrote about using variables with CSS pre-processors. Having the ability to use variables will save you enough time to justify learning pre-processors, but there are two other features in Sass and LESS that will save you even more time: nesting and mixins.

Sass versus LESS

Pre-processors allow you to code in a language that’s similar to CSS, but with additional features. Most people are on the fence about adding them to their repertoire because there are two competing high-profile standards: LESS and Sass.

I remember having a similar problem a few years ago trying to decide between jQuery mobile and other JavaScript libraries. Sass and LESS are so similar that it almost doesn’t really matter which one you learn. Switching in between them is pretty easy, so ultimately it’s learning about the concepts that matters. Yes, there are some features specific to each language like guarded mixins in LESS and conditionals in Sass, but I imagine that as the languages develop further, they will each keep up with the other.

Pick one

The important thing is what you plan to do with the languages. If you’re planning to use a framework like BootStrap, from Twitter, then it’s a good idea to go with LESS because Boostrap was written with LESS. If you want a nearly identical framework that uses Sass, check out Foundation. Although Sass requires you to install Ruby, you’ll want to use something like CodeKit to manage your pre-processors.

My advice: Pick one framework and get good with it.

Before we start coding, keep in mind that when I’m talking about Sass, I’m speaking of the newer version with an .scss extension. It’s easier to learn for CSS users because it lets you use CSS syntax and style you may already know.

Nesting

Besides variables, another awesome thing you can do with pre-processors is nesting. Let’s say you’ve developed a simple horizontal nav bar for your site.

<ul>
<li><a href="#">Home</a></li>
<li><a href="#">About us</a></li>
<li><a href="#">Info</a></li>
</ul>

Here’s a typical way to write CSS to make this into a nav bar:

ul {
margin: 0;
padding: 0;
font: bold 1em/1.2em Helvetica, Arial;
}
ul li {
list-style: none;
}
ul li a {
float: left;
background: #BA0436;
text-decoration: none;
color: white;
display: block;
padding: 10px;
}
ul li a:hover {
background: #EEC25C;
color: black;
}

A simple nav bar written with CSS

As your CSS file gets bigger, the number of styles that are children of other styles increases. In either Sass or LESS, you can do the same thing, like this:

ul {
margin: 0;
padding: 0;
font: bold 1em/1.2em Helvetica, Arial;
li {
list-style: none;
a {
float: left;
background: #BA0436;
text-decoration: none;
color: white;
display: block;
padding: 10px;
&:hover {
background: #EEC25C;
color: black;
}
}
}
}

This way, the li selector is written inside the ul selector and the a selector is inside the li selector as if they were another rule. Notice that because we are using a pseudo-class, I have to add the ampersand (&) before the :hover selector.

Nesting doesn’t necessarily save you a ton of time, but it makes your code cleaner. When coding CSS, designers can sometimes add new rules where they don’t belong: nesting helps you keep everything tidy.

Both Sass and LESS implement mixins the same way, so there’s no need to show you the difference between the two.

Mixins

If you liked variables, you’re going to love mixins. They are snippets of code you can reuse over and over in your CSS. You can use them with variables to make coding in CSS easier. Let’s take a look at how you would code a simple top-to-bottom gradient using regular CSS.

.mybox {
  background-color: #333745;
  background-image: -webkit-gradient(linear, left top, left bottom, from(#DAEDE2),
to(#77C4D3));
  background-image: -webkit-linear-gradient(top, #DAEDE2, #77C4D3);
  background-image: -moz-linear-gradient(top, #DAEDE2, #77C4D3);
  background-image: -o-linear-gradient(top, #DAEDE2, #77C4D3);
  background-image: linear-gradient(to bottom, #DAEDE2, #77C4D3);
}

To make sure the gradient displays in as many older browsers as possible, we have to include code for different versions of Safari, Google Chrome, Firefox and Opera. It almost makes you want to stop doing gradients in your CSS. We can use variables to simplify this. Let’s try that with a Sass example.

First, we’ll create two variables for the colors somewhere in our .scss file:

$from: #333745;
$to: #77C4D3;

Once we have that, we can modify our gradient to use the variables:

$from: #333745;
$to: #77C4D3;
.mybox {
  background-color: $from;
  background-image: -webkit-gradient(linear, left top, left bottom, from($from), to($to));
  background-image: -webkit-linear-gradient(top, $from, $to);
  background-image: -moz-linear-gradient(top, $from, $to);
  background-image: -o-linear-gradient(top, $from, $to);
  background-image: linear-gradient(to bottom, $from, $to);
}

Modifying the gradients to use variables works great and it will save you a lot of time. But what if you wanted to reuse this for other declarations? That’s where mixins come in. You can create snippets of code and reuse them. Let’s create a mixin for linear gradients using the code above as a base.

$from: #333745;
$to: #77C4D3;
@mixin lgradient {
  background-color: $from;
  background-image: -webkit-gradient(linear, left top, left bottom, from($from), to($to));
  background-image: -webkit-linear-gradient(top, $from, $to);
  background-image: -moz-linear-gradient(top, $from, $to);
  background-image: -o-linear-gradient(top, $from, $to);
  background-image: linear-gradient(to bottom, $from, $to);
}

This makes working with gradients more manageable, but it will only work with one set of from/to colors. We can easily improve on this by putting these variables within our mixin. If you know JavaScript, this is like writing a function. Here’s the syntax in Sass.

@mixin lgradient($from: #333745, $to: #77C4D3) {
background-color: $from;
background-image: -webkit-gradient(linear, left top, left bottom, from($from), to($to));
background-image: -webkit-linear-gradient(top, $from, $to);
background-image: -moz-linear-gradient(top, $from, $to);
background-image: -o-linear-gradient(top, $from, $to);
background-image:  linear-gradient(to bottom, $from, $to);
}

Now, when we want to use our gradient in our box, we can just type the following:

.mybox {
@include lgradient;
}

Adding this line of code will create the gradient with the default colors, but since they’re variables, you can create any top-to-bottom linear gradient and specify the colors in your .scss file.

.mybox {
@include lgradient(#FCC,#FEE);
}

Now you have an easier way to create gradients. Let’s check out the code in LESS:

.lgradient(@from, @to) {
background-color: @from;
background-image: -webkit-gradient(linear, left top, left bottom, from(@from),
to(@to));
background-image: -webkit-linear-gradient(top, @from, @to);
background-image: -moz-linear-gradient(top, @from, @to);
background-image: -o-linear-gradient(top, @from, @to);
background-image: linear-gradient(to bottom, @from, @to);
}
.mybox {
 .lgradient(#CCC,#DDD);
}

Pretty similar, except that the dollar signs ($) are replaced by @ symbols and there is no mixin keyword. You can see how pre-processors will help you write CSS more efficiently. If you haven’t already taken the plunge, what are you waiting for?


Interested in more?
• All web + interactive courses on lynda.com
• All courses from Ray Villalobos on lynda.com

Suggested courses to watch next:
• CSS: Core Concepts
 CSS Fundamentals
 CSS3 First Look
 Managing CSS in Dreamweaver

An introduction to LESS and Sass pre-processed CSS languages

Published by | Friday, July 20th, 2012

Getting started on something new can be challenging, especially when the shear number of competing technologies that do similar things can make it tough to choose which one to give your attention to. One of the hot new trends in web design is CSS pre-processed languages and there’s two big ones vying for your attention—LESS and Sass. LESS and Sass are both ways of writing CSS code with a syntax that allows you to use features not yet available with Cascading Style Sheets (CSS), such as variables, nesting, conditionals, and more.

What are pre-processed CSS languages?

Pre-processed CSS languages add features to CSS that aren’t there yet—like variables, conditionals, and functions. They’re called pre-processed, because their final step is a processing, also called compiling, that converts the pre-processed language to regular CSS. In a nutshell, what you use on your site ends up being plain vanilla CSS, but comes as a result of processing the LESS, Sass, or other pre-processed language files you create.

Why use pre-processed CSS at all?

It’s hard enough becoming proficient with CSS, HTML, JavaScript, and jQuery, so if you can do the same thing with CSS, why would you want to submit yourself to learning an additonal language? Whether or not learning LESS or Sass is right for you comes down to whether or not the new languages will make you better, faster, or more efficient. Both LESS and Sass introduce variables into CSS, which I have found to be a very efficient detail that has made learning the new languages worthwhile for me.

For example, when you build a large web site, there’s usually a palette of colors you’re using throughout the site, and you might, for instance, be using one color for your article headlines that you also want to use on your links in the bottom navigation.

Example results of Less and SASS coding.

Example of web site design using the same color for article headlines and bottom navigation links.

Doing that with CSS is pretty easy:

CSS code that alters the color text within a web design.

While that works well, what if you wanted to use that same color in 20 or 30 selectors, or in gradients with a bunch of different browser prefixes? Both Sass and LESS will allow you to create variables which make global changes on elements a breeze. The code for this color application—with the assigned variable @myColor—looks like this in LESS:


LESS CSS pre-processed code that alters web design color. 

And—with the assigned variable $myColor—like this in Sass:

SASS CSS pre-processed code that alters web design color. 

Looks pretty much like CSS, right? Both LESS and Sass let you use the regular CSS code you already know so you really don’t have to learn a whole new way of doing things—just some additional rules. Even if the only thing you get out of pre-processed CSS is the ability to use variables, that alone will save you a lot of time, and it’s technology that saves you time that you need to spend your time investigating.

Using a Compiler application

Unfortunately, when you use pre-processed languages like SASS and LESS, you do need to compile the code into CSS. That can be done in a variety of ways. LESS, for example can be downloaded as a Javascript file that can be added to the project, or as a command-line tool for either your local machine or your server. Sass installation is also a command-line install. They try to make things easier by letting you define which folders should get automatically processed, but I still wouldn’t describe it as a user friendly experience for your average designer (which is why most graphic designers who use CSS have never tried using LESS or Sass).

Thankfully, there are some compiler applications that take care of processing files for you, and update things visually. My favorite application for compiling pre-processed languages is CodeKit. It handles LESS and Sass really well, and it also lets you process Haml, CoffeeScript, and even JavaScript.

A screenshot of the CodeKit compiler.

The CodeKit compiler.

You can also have CodeKit ‘mini-fy’ all of your files, not just your CSS. That means that it can spit out a different version of your code without comments, tabs, or extra spaces, which will make your files a lot smaller (something I recommend that you be doing regularly anyway).

If you use frameworks like BootStrap or jQuery Mobile, you can import them into your projects through CodeKit from a central location. When a new version of jQuery comes out, you can simply replace one copy and all of your projects will auto-update with the latest copy.

On a PC or Linux machine, things are a bit less rosy. There is a nice LESS compiler called SimpLESS which helps, but it’s not as feature-full as CodeKit.

Get Started

There are many more things you can do with LESS and Sass. If you’ve been on the fence about them, I recommend you give them a shot. Starting simply with variables is easy enough if you are already familiar with CSS, and if you’re like me, you’ll find using variables will make your life immediately easier. Even if you’re into command-line tools, I recommend you take a look at something like CodeKit or SimpLESS.

Should I use LESS or Sass?

Both LESS and Sass are pretty good, especially if you’re just getting started. For me, LESS has a bit of an edge since I’m currently digging into Twitter’s Bootstrap Framework, which makes it a breeze to scaffold and build web sites quickly (it is written in LESS). Sass takes the cake if you’re working with Ruby on Rails projects since it was written in Ruby. Ultimately, which pre-processed language you choose doesn’t really matter since they’re both tools that will make you more efficient, and that’s always worth an investment in time. Pick one and wedge it into the workflow for your next project. It may take you a bit longer to finish, but it will also change the way you code for the better.

 

Interested in more?
• All web + interactive courses on lynda.com
• All courses from Ray Villalobos on lynda.com

Suggested courses to watch next:
CSS: Core Concepts
 CSS Fundamentals
 CSS3 First Look
 Managing CSS in Dreamweaver