After spending some time learning how to make websites, you were contacted by your first client. You felt pretty confident, you got the design (it was OK, only 15 pages), and you were ready to kick off.
You started creating the first page the usual way: put a bit of HTML code, then style it with CSS... And it looked good, just like the design. By the time you got to the third page, you were a bit annoyed because you had to type those vendor prefixes every single time, but hey, that's CSS. You created nice red buttons you were using on the first three pages, but you soon realized that you needed blue buttons, too. So, you made another set of properties almost identical to the ones the red button had. You only changed the color. At the time this process seemed boring but necessary.
By the time you finished the project, you had chunks of the same code all over your stylesheet that you had to type manually, but that's not even the worst thing - the client finally took a look at the finished product, and wasn't really satisfied with that shade of blue you used everywhere on the website. So you had to go back and find aaaaall the places where you used that color and change it, one by one, line by line, border-color by border-color... You got lost and frustrated quite a few times, but you finally did it. So the shade of blue was now correct... Except on one page where, for some unknown reason, the wrong shade still remained. Well, you knew the drill: go back, find it and change it.
But then you started to wonder: "What if the client wants another change in the future? Will I have to go through all this again? If only there was some other way to write CSS that will help me make a website faster and maintain it more easily."
We have two words for you: There is! Actually, one word was enough: Sass.
Sass is a CSS preprocessor, an extension of CSS. Think of it as a way to write CSS using some things that are not native to CSS, but make your life, and your development much easier, and in the end, after compiling, look just like CSS. Ok, you like how it sounds but don't quite understand what those neat things are. Well, we'll just have to dive a bit deeper into Sass in order to explain it correctly. We'll show you some really cool features. Prepare to be amazed.
Just a note before we start. Sass actually has two syntaxes. Let's just say you have two ways of writing Sass, but in the end they both do the same thing. The new, and mostly used syntax is called SCSS (Sassy CSS) and the old one is called just Sass. We will be using SCSS syntax in our examples, and the file extension associated with this syntax is .scss. So don't get confused when you see it. It's still Sass.
We're just going to talk about Sass features and syntax. If you want to setup and use Sass, just follow any of the dozens of tutorials you can find online, such as the official one.
If you are familiar with any programming language, the use of variables is nothing new to you. But even if you're not, the concept is quite easy to grasp. Variables are stored values you can use whenever you need them. Let's be more practical. Remember when your client wasn't satisfied with the shade of blue you used, and you had to comb through every stylesheet, and every line of that stylesheet in order to find and change the color? With Sass it would be a matter of seconds. Literally.
Let's store that blue color in a variable:
$color-blue: #0000ff;
Now, whenever we want to use that same color, we just use a variable:
.button {
background-color: $color-blue;
}
h1 {
color: $color-blue;
}
The sweetest thing about variables is how easily maintainable your website is. Ok, your client doesn't like that shade? No problem, we change the color in the variable and that color will be applied on all the elements that use that very variable.
$color-blue: #0000e5;
And voilà, job's done.
Variables start with $ sign, and you can store any value you could use later: font-family, border-radius, etc. Compiled CSS output will show only the value and your CSS file will look like this:
.button {
background-color: #0000e5;
}
Extends are one of those cool Sass features that save us from unnecessary repetition of the same code. Extends basically let one selector inherit styles from another selector. Let's take your project as an example again. You had default buttons that were red:
.button {
background-color: red;
border: none;
color: white;
padding: 15px 32px;
text-align: center;
text-decoration: none;
display: inline-block;
font-size: 16px;
}
Then you needed another button that would be different in background color. What you did at the time when you didn't know about Sass, was copying the same code and just replacing the background color, so your code looked like this:
.button {
background-color: red;
border: none;
color: white;
padding: 15px 32px;
text-align: center;
text-decoration: none;
display: inline-block;
font-size: 16px;
}
.button-blue {
background-color: blue;
border: none;
color: white;
padding: 15px 32px;
text-align: center;
text-decoration: none;
display: inline-block;
font-size: 16px;
}
Now, if we do it the Sass way using extends, it looks like this:
.button {
background-color: red;
border: none;
color: white;
padding: 15px 32px;
text-align: center;
text-decoration: none;
display: inline-block;
font-size: 16px;
}
.button-blue {
@extend .button;
background-color: blue;
}
The blue button basically inherits all the properties the red button has, and just changes or adds its own signature feature, in this case, the background color.
Our code is neat and DRY, and the compiled CSS output will show all the properties the blue button inherited from the default (red) one, combined with the new ones.
.button-blue {
border: none;
color: white;
padding: 15px 32px;
text-align: center;
text-decoration: none;
display: inline-block;
font-size: 16px;
background-color: blue;
}
Placeholders are a special type of extends. You can look at placeholders as classes that define some set of properties, but those classes are never used in HTML, and are not generated in CSS just because they were defined in SCSS. You actually have to call or @extend them within a selector in order for them to be compiled. Placeholders are prefixed by the % sign:
%border-green {
border-color: green;
border-width: 1px;
border-style: solid;
}
Now, whenever we need to put a green border on an element, we just extend this placeholder within that element's selector.
.box {
@extend %border-green;
}
h1 {
@extend %border-green;
}
The compiled CSS output is:
.box, h1 {
border-color: green;
border-width: 1px;
border-style: solid;
}
Mixins are another powerful feature that helps you create reusable chunks of code. But there is one additional feature that mixins have: they can take arguments.
You already admitted you got a bit annoyed whenever you had to type vendor prefixes manually. We feel you. But the easier way to do it is with Sass mixins.
First we create a mixin. We use the @mixin directive, give it a name, and also pass an argument, which is optional.
@mixin transform($val) {
-webkit-transform: $val;
-moz-transform: $val;
-ms-transform: $val;
transform: $val;
}
Then, to use it, we need to @include it.
.box {
@include transform(scale(2,2));
}
Now, whenever we need to use the transform property, all vendor prefixes will be inserted for us, and by passing an argument, the use of this mixin is more flexible.
The compiled CSS output looks like this:
.box {
-webkit-transform: scale(2,2);
-moz-transform: scale(2,2);
-ms-transform: scale(2,2);
transform: scale(2,2);
}
Nesting provides you with a visual hierarchy of CSS selectors, which makes your (S)CSS easier to read and maintain.
We'll go straight to an example.
Let's say we have an article. That article consists of a title and some text. Now, we have to style both the article and its elements. The code written using Sass nesting powers looks like this:
.article {
width: 300px;
height: 300px;
.article-title {
font-size: 20px;
color: gray;
}
.article-text {
font-size: 14px;
color: green;
}
}
When we look at the code it's pretty obvious that .article-title and .article-text are children of .article, and which styles belong to which selector.
So, to use nesting, we just enclose a selector inside another selector's scope. The compiled CSS output looks like this:
.article {
width: 300px;
height: 300px;
}
.article .article-title {
font-size: 20px;
color: gray;
}
.article .article-text {
font-size: 14px;
color: green;
}
Sass nesting is cool, and when you start using it, you'll want to go deeper and deeper. But it's generally considered a bad idea. Let's take a look at the next chunk of code:
.page {
//some code
.content {
//some code
.main {
//some code
.header {
//some code
.navigation {
//some code
.navigation-list {
//some code
.navigation-item {
//some code
}
}
}
}
}
}
}
The last element in this nesting chaos is .navigation-item, and the code for that element compiles to:
.page .content .main .header .navigation .navigation-list .navigation-item {
//some code
}
When you look at the compiled CSS output, nesting too many selectors does not only look ugly, but it's also bad for rendering performance, and can cause problems with selector specificity. The general advice you'll find across the internet, is to avoid nesting more than 3 to 5 levels deep.
Another cool thing about nesting is that you can reference the parent selector without having to explicitly type its name - using the & symbol.
a {
color: red;
&:hover {
color: blue;
}
}
This will compile into:
a {
color: red;
}
a:hover {
color: blue;
}
Apart from nesting selectors, you can also nest properties within the same namespace. An example is worth a thousand definitions:
.box {
border: {
color: red;
width: 1px;
style: solid;
}
}
This compiles into:
.box {
border-color: red;
border-width: 1px;
border-style: solid;
}
Sass imports are a feature that makes your project and stylesheets beautifully organized and easily maintainable.
This feature allows you to create pieces of code or small stylesheets that can later be @imported and combined into one stylesheet. Yeah, one can argue that separation of stylesheets is possible with plain CSS too, and that's true. But in that case you would have multiple HTTP requests and we don't want unnecessary HTTP requests to happen, riiight? Right.
The main idea is to keep related code in separate files that can be easily edited, updated or otherwise maintained. By using @import directives, we combine all those files into one main file.
If you want to import a file and not compile it as CSS, then a partial is a way to go. Partials are just files named with a leading underscore, which is a Sass way of saying that the file is actually a partial and that it shouldn't be compiled into an independent CSS file.
Let's say we have separate partials for button styles, typography and layout. All the code that is related to buttons will be kept in _buttons.scss, the code related to layout will be in _layout.scss, and the code related to typography will be in _typography.scss. Those 3 partials will be imported into the main file (that will eventually get compiled as CSS) like this:
@import "buttons";
@import "typography";
@import "layout";
Note that you don't have to include the underscore or the file extension (.scss) when importing a partial.
Now just imagine... We need to edit buttons? No problem, we know exactly where to look. No more looking through all the files searching for that one line that says .button. Beautiful, you have to agree.
With Sass you are allowed to do some math operations like addition, subtraction, multiplication, division...
Maybe you need to create a secondary font that is just a bit larger than your primary font? No problem, just use the addition operator (you may remember it as + sign).
$font-primary: 14px;
.font-secondary {
font-size: $font-primary + 2px;
}
This compiles to:
.font-secondary {
font-size: 16px;
}
Or maybe you need to create a small container that is always half the size of your primary container?
$containerWidth: 1024px;
.container-small {
width: $containerWidth / 2;
}
The previous block compiles to:
.container-small {
width: 512px;
}
This way, the small container will always be half the size of your primary container, even if you decide to change the width of the primary container.
There are bunch of other arithmetic things you can do with Sass. You can play with numbers, strings and even colors. Math has just become cool again.
We know we've got your attention by now, and that you will start using Sass after reading this, but we still have one more super cool thing to present to you. Meet Sass functions.
Sass functions help you unleash your inner programmer. Even if you've never learned or used a programming language, Sass gives you a glimpse of that feeling.
First we'll create the function with a @function directive followed by a name and arguments. Inside the curly braces, we'll put all the necessary logic.
The example is a simple function that calculates line height based on font size.
@function calculateLineHeight ($fontSize) {
@return $fontSize * 1.6;
}
The next step is to actually use it within a selector:
$fontSize: 16px;
h2 {
font-size: $fontSize;
line-height: calculateLineHeight($fontSize);
}
The CSS output will be:
h2 {
font-size: 16px;
line-height: 25.6px;
}
Come on, you have to admit that even a simple function like this one is cool. Now just imagine all the magic you can create with this.
But apart from creating your own functions, Sass already comes with a bunch of predefined functions you can use out of the box.
We'll show you one, and your next task could be to look up others:
darken($color, $amount)
This function takes the color you pass as the first argument and makes it darker by the amount you pass as the second argument. Just like that.
$color-gray: #d3d3d3;
a {
color: $color-gray;
&:hover {
color: darken($color-gray, 5%);
}
}
As you might noticed, in the previous example we used various Sass goodies. Can you find them?
We tried to bring Sass concepts closer to you, but to fully understand how powerful Sass really is, we encourage you to check the official Sass website. You'll find loads of treats there.
We are pretty sure we know what you're thinking right now: "How did I even manage to make a website without Sass?". Well, don't beat yourself up too much, we've all been there. The most important thing is now you know about it and there's no reason not to use it from now on. You'll be more productive and faster in developing a website, and the maintenance of your websites won't be such a pain in the neck ever again.
The conclusion? One does not simply write CSS without Sass.
To be honest, you can but you don't have to and you shouldn't. Not when there is a better, easier and more fun way to do it. Embrace Sass.
We are Creitive, digital innovation agency If you want to learn more, check out our Mobile app development services
