Thursday, 1 May 2014

Filled Under:

Getting Started With SASS

04:40:00

You’ve probably heard a lot about things like Sass, Grunt, Less or even Gulp and other web deployment related workflows lately. People everywhere are raving over Sass and Grunt as if they’re gods gift to front-end developers. 

I wouldn’t go that far, but nonetheless they can save you time, make your code more efficient and make your workflow a little more sophisticated. For those of you who may have heard of Sass or Gulp, but have never delved into them, now’s a great time to start. Today, I’ll be focusing on understanding Sass and introducing how to work with it.
Ok let’s get into this.


What is Sass

Sass stands for Syntactically Awesome Style Sheets and is a CSS preprocessing language. It’s basically a way of writing an extended version of CSS with syntax advancements. Sass stylesheets are processed by a program (like Codekit, Gulp or Grunt), and turned into regular CSS stylesheets. However, they do not extend the CSS standard itself.
There are a number of common misconceptions about Sass for people who have never used it. One of these is how Sass actually works. It’s not a replacement to CSS, it is merely a way of writing CSS in a more concise way, which then gets converted (locally) into CSS. The idea is that it enables you to write CSS in a way that is less repetitive, with traditional programming concepts (extended CSS syntax).


Sass converts to CSS

This is something I really wanted to clear up, as a lot of people tend to think you actually deploy Sass (.scss or .sass) files on a live server and the browser reads it. Unfortunately this is not the case, if you write a style sheet in Sass, it needs to be converted to a .css file for the browser to read it. This is usually done locally in development and then the .css output is used on a server. Technically you could convert it server-side, however that’s a beast for another day. So if it ends up as CSS anyway, what’s the point right? Let me explain.


Why Sass

If you talk to any computer programmer about front-end development, they’ll immediately tell you how “stupid” languages like HTML and CSS are. They’ll tell you how frustrating and illogical it is to continually write the same code over and over without a way of predefining things.
The truth is, they’re kinda right. Computer programming languages like C++ have a common core concept – DRY (don’t repeat yourself) which is a way of to preventing code from becoming a huge copy & paste fest. It also keeps things concise. This means their languages have all these super-cool ways of defining functions and system knowledge in advance. Furthermore it makes maintenance and changes to existing code more logical and less contradictory.
Ringing any bells yet? These are all things that CSS doesn’t do very well, so you can understand your programmer friend’s frustration right? This is where Sass comes in. If you write in Sass you’re getting all these cool syntax improvements that do all those things above. Plus you can tell you programmer friend that front-end development isn’t really all that bad.


How To Write Sass

A common source of confusion seems to be the different ways to write with Sass. You may have seen tutorials that look completely different – one looks similar to CSS and the other looks totally different. This is because Sass has two syntaxes. The new main syntax (as of Sass 3) is known as “SCSS” (for “Sassy CSS”), and is a superset of CSS3’s syntax. This means that every valid CSS3 stylesheet is valid SCSS as well. SCSS files use the extension .scss.
The second, older syntax is known as the indented syntax (or just “Sass”). Inspired by Haml’s terseness, it’s intended for people who prefer conciseness over similarity to CSS. Instead of brackets and semicolons, it uses the indentation of lines to specify blocks. Although no longer the primary syntax, the indented syntax will continue to be supported. Files in the indented syntax use the extension .sass.
Although the .sass version is cool and ultra-nerdy, I prefer to use .scss simply because I found tethering from regular CSS more logical.
Here’s a quick example of both with their respective CSS output:

.scss

HTML
// Colors
$color-primary :#C6538C; // pink C6538C
$color-background :#F7F7F7; // off-white F7F7F7
$color-text :#333333; // off-black 333333
$color-hover :#e7b6ce; // pale pink FF00FF

body {
background: $color-background;
color: $colour-text;
}

// An example of nested styles
a {
color:$colour-primary;

&:hover {
color:$colour-hover;
}
}

.sass

HTML
// Colors
$color-primary: #c6538c // pink C6538C
$color-background: #f7f7f7 // off-white F7F7F7
$color-text: #333333 // off-black 333333
$color-hover: #e7b6ce // pale pink FF00FF

body
background: $color-background
color: $color-text

// An example of nested styles
a
color: $colour-primary
&:hover
color: $colour-hover

.CSS

CSS
body {
background: #f7f7f7;
color: #333333;
}

a {
color: #c6538c;
}
a:hover {
color: #e7b6ce;
}
 

Syntax Usage

As you can see in the example above writing in Sass is a little different to CSS. I mentioned earlier that Sass has a number of syntax advancements, let’s look at how they work, as well as how to use them.


Variables

Variables are a way of defining and storing values that you will be re-using throughout your stylesheet. You set variables for things like colors, fonts, sizes, padding, margins…pretty much anything you want. The concept is similar to variables in other languages like PHP and JavaScript.
The idea is that you can predefine styles and then re-use them without having to copy/past lengthly CSS properties and values. Furthermore it makes adjustments a whole lot easier as you only need to change the variable value, rather than find/replace every instance of the a CSS value. Sass uses the $ symbol to make something a variable. Here’s an example:
HTML
$font-stack: Helvetica, sans-serif;
$primary-color: #333;
$brand-color: #327cd6;

body {
font: 100% $font-stack;
color: $primary-color;
background: $brand-color;
}
The resulting CSS would be:
CSS
body {
font: 100% Helvetica, sans-serif;
color: #333333;
background: #327cd6;
}
 

Nesting

By default CSS doesn’t have a nested structure (unlike HTML)  - it’s cascading. However with Sass you can nest your styling as you would see its visual hierarchy in HTML. This gives it a more logical structure as you can nest element and class styling inside each-other.  Here’s an example:
 
HTML
nav {
ul {
margin: 0;
padding: 0;
list-style: none;
}

li { display: inline-block; }

a {
font-weight: bold;
&:hover { color: red; }
}
}
The resulting CSS would be:
CSS
nav ul {
margin: 0;
padding: 0;
list-style: none;
}
nav li {
display: inline-block;
}
nav a {
font-weight: bold;
}
nav a:hover {
color: red;
}
 

Importing

SASS builds on top of the existing CSS @import property, by importing other .scss files and compiling them as a .css output file. Using this technique on a server in regular CSS is generally frowned upon as it creates additional HTTP requests. However with Sass, because all the importing is done locally, there’s no issues. It’s a great way of working as you can keep all your styling in a modular setup with separate .scss files for different things. For example you could have a reset.scss, base.scss, navigation.scss, footer.scss, mediaqueries.scss etc… and then a final file which compiles everything.
CSS
@import 'base-styling';
Note that when importing, you don’t need to specify the file extension -.scss. Sass is smart and will figure it out for you.


Mixins

Mixins are awesome. Mixins let you make groups of CSS declarations that you want to reuse throughout your styling. You can even pass in values to make your mixin more flexible. Here’s an example:
CSS
@mixin border-radius($radius) {
-webkit-border-radius: $radius;
-moz-border-radius: $radius;
-ms-border-radius: $radius;
-o-border-radius: $radius;
border-radius: $radius;
}

.box { @include border-radius(10px); }
This would output:
CSS
.box {
-webkit-border-radius: 10px;
-moz-border-radius: 10px;
-ms-border-radius: 10px;
-o-border-radius: 10px;
border-radius: 10px;
}
 

Extend

Extend is the core conept of Sass that’s intended for DRY coding. It may be a little hard to understand at first, but it’s super useful. It allows you to apply existing class styling to other (multiple) classes. Meaning once you write one style, you don’t need to list a whole bunch of elements that use that same styling. Here’s an example:
CSS
.random-box {
color:#000;
width:100%;
}

.first-box {
@extend .random-box;
background:red;
}

.second-box {
@extend .random-box;
backgrond:green;
}

.third-box {
@extend .random-box;
background:blue;
}
This would output:
CSS
.random-box, .first-box, .second-box, .third-box {
color: #000;
width: 100%;
}

.first-box {
background: red;
}

.second-box {
backgrond: green;
}

.third-box {
background: blue;
}
 

Operators

It would be pretty handy if CSS could do some math right? Well with Sass, you can. It’s particularly useful for setting up grids with percentages so you don’t have to do all the calculations manually yourself. The standard math operations (+, -, *, / and %) are supported for numbers. For colors there are functions built into Sass which target lightness, hue, saturation, and more.
CSS
.container {

width: 100%; }

article {
float: left;
width: 600px / 960px * 100%;
}

aside {
float: right;
width: 300px / 960px * 100%;
}
Sass let’s you do simple or complex calculations and output the result in percentages. In this example, we’ve split the article and aside into the sizes we want in pixels, however we don’t know the percentage to make the layout fluid so we simply tell Sass to calculate it. Here’s the result in CSS:
CSS
.container {
width: 100%;
max-width: 960px;
}

article {
float: left;
width: 62.5%;
}

aside {
float: right;
width: 31.25%;
}
 

Summary

As you can see, Sass adds some much needed functionality and additional syntax to CSS, making workflow less repetitive and more future-proof. While Sass definitely has a bit of a learning curve, particularly given CSS’s cascading structure, once you start using it, you’ll wonder why you didn’t earlier.
Today I’ve barely scratched the surface of what’s possible with Sass, however hopefully you have a better understanding of how things work. I’ve also compiled a few links for further reading and learning.

Additional Reading

5 Reasons for Picking up Sass *Today* - Tuts+
Getting Started with Sass – A List Apart
The Many Ways To Work With CSS Preprocessors – Jeff Croft.
thesassway.com
Mastering Sass: Lesson 1 - Tuts+

0 comments:

Post a Comment