Speeding up Workflow with Sass
Creating a Color Palette
We start with this pretty much blank site, and add some colors.
Let’s Sass things up with some variables.
To modify the color variables, there are some functions you can use, such as lighten(). It takes two arguments, the first being the variable, the second being the percent lighter you want it to be. This is nice because it changes it dynamically, so if we were to change the color for the $text-color variable later it lighten that one instead. Notice how Sass calculated the hex code of the new color and put that into the CSS. There is a darken() function as well, which works the same way.
Once again thinking as DRY as possible, this works well for variables.
In art, there are complimentary colors, which are opposite on the color wheel.
In Sass, you can generate a color’s compliment using the complement() function. Note that in this example, the lighten color is being calculated off of the calculated complement color.
There are a whole bunch of other functions, like desaturate, hue, opacity, even a mix function that let’s you mix multiple colors together.
Learn more about color operations and keyword arguments in the documentation.
It’s good to have one stylesheet, as it reduces the requests when loading a site. However, for devs one huge stylesheet is a pain to work with, so it’s better to have multiple files, all of which are imported by the one stylesheet that’s loaded by the site. A good practice is to have a sheet for just your Sass variables.
So, we create a separate sheet for that, then import it using @import, followed by the name of the file to import in quotes, followed by a semicolon.
Note: the file name was started with an underscore. They did this so that Sass would not create a separate CSS file for it. If we hadn’t used an underscore, there –watch would make a variables.css file, which we don’t want. This is known as a partial Sass file.
Within the _variables file, it’s good to make use of Scss comments (which appear to be like JS’s, just two //) to divide up the sections.
Make another stylesheet for global styles, and suddenly there’s no actually css in the main.css file that gets loaded. This is normal for a lot of Sass projects, it’ll just be a list of @import’s.
Another convention is to make a folder called pages, then create a stylesheet for each page of the site to import. The order matters – you need the variables and mixins first because the other stylesheets depend on and use them. Additionally, like normal CSS, things cascade and will overwrite if they’re called later.
Another example is if you need to do special styling for blackberry browsers. You could start by importing main.css, which contains imports to all those other stylesheets, and then add your own styles on top of that. Additionally, you wouldn’t start the name with an underscore, so you’d get a separate blackberry.css file as well.
If you want to use normalize or reset.css, simply import that first.
Working with Sass Libraries
Bootstrap is a UI library/framework that gives you a flexible grid system and predefined styles. It was originally written in LESS, a competitor to Sass, but people have fixed this for you and it works well with Sass. Foundation is another responsive framework that was written in Sass.
There are also Sass libraries, which focus on helping your write Sass. Compass is the most popular one, but there are others, like Bourban, which is a bit simpler. You’ll need to use the command line to install Bourban, which will create a folder where specified with the needed files. You can then read through those to see what’s available to you, like button mixins for example.
To import, just @import like you would any other scss file. Now, we can use the library. The linear-gradient property is a good example as it’s not yet standardized across all browsers. Bourban takes one declaration and auto includes the vendor prefixes you need for that for each browser.
It’s also helpful for defining font families. You can see here it put in the rest of the back up fonts for you in the CSS, based off the $lucida-grande variable.
Sass let’s you build your own functions. We’ll start by making some div’s.
We’re going to build a Sass machine, which isn’t necessarily a normal site. When you give it a color, it will show you a color and the percent make up of it of RGB by size.
We’ll start by defining a color variable and set the first div to it, then float the other div’s so they’re all in a line.
Next we’ll set the background colors for the rbg divs.
Now we need their width to be overwritten and represent the amount of red, green or blue in our color. There’s a function called red() and we can pass it an argument, which will return the amount of red in the color from 0-255. We’ll set the red div’s width to that. We need it to be in px’s, so we’ll add that as well.
This ends up putting everything in quotes though, which we don’t want. Luckily we can use the unquote() function to fix that.
It would be better to do this as a function though. They’re written at the top like mixins and variables. You start it with @function, then the name of the function, any arguments you want to pass in (note that these parameters need to start with a $), then curly braces for the code. Within that you need to use @return, which is what the function returns.
We then plug that in and get this.
And we’re done! We can now change the value of the $color variable and the div’s below will change accordingly.
Speeding up Workflow with Sass
Common mistake – forgetting a semi colon. Sass is pretty strict about this. We forgot one for our $margin variable, and you can see Sass is sassing us about it at the top of our html and css pages
Note that it adds the content at the top of your html using a before psuedo class and the content property.
If you mess up a curly brace, the compiler won’t know anything’s wrong til it gets to the end of the file. Here, we forgot a closing brace for the h1. Sass thought the .entry’s closing brace was the h1’s now, and now thinks there is none for the .entry. Note that because of this it’s telling you the error at the end of the file, which is wrong. It basically counts the number of braces and let’s you know if it’s off.
There are lots of Sass options, which you can access from your console with sass –help. There are a lot of cool options, like –style, which let’s you modify how the css is outputted (by default it’s nested like we’ve seen before). If you do compressed, you can minify a scss file into css.
Note that you can modify the output so it puts that in the css file, rather than printing it to the console, by putting :filenameyouwantittogoto after it.
Alternatively, you can use the expanded style and have it print out normal CSS rather than the nested kind.
Another cool option is –line-numbers, or -l, which will put in CSS comments letting you know where to look in the scss file/what line for the corresponding code.
Finally, there is a @warn directive you can use for mixins to warn devs it might be depreciated in the console.
This didn’t come up in the lesson, but for Sass comments, you do // for Sass only comments, and /**/ for CSS comments.
Working with Media Queries
We’ll start with a basic responsive site.
In normal CSS, you’d have your media query at the bottom like this:
With Sass, you can actually just nest them into the selector.
And just like that, we’ve replaced the original media query with our nesting.
In the CSS, it will create multiple, nested media queries.
Interpolation and if/else Loops
Interpolation is helpful for repeating patterns. In the example below, just a mixin wouldn’t work because you need it to be dynamic based off the class name.
To do interpolation, use a pound sign then curly braces, putting the variable name inside of them. Now we can use the mixin and it will dynamically update the color based on the class name. You can add on other classes and selectors to the original class, etc.
Here’s using the same technique to set the background image.
Alternatively you could concatenate them.
We can do if/else statements as well. Let’s say if the color is red we want to do something different. You write it with @if, then the the condition, then put the code in curly braces. Here, if the color is red we add a border.
You can compare numbers for the condition as well. Here, we adjust a padding based on width for a div. Note that if the condition isn’t met and there are no styles to apply for the div, Sass won’t print the div at all to the CSS, since there are no styles for it.
To use an else, just do @else. To use an else if, just do @else if.
Creating Loops with @for and @each
We’ll start with a bunch of divs all styled the same.
Our goal is to set a color for each one slightly lighter than the last. To do a for loop, type @for, then $i, then your condition. Typing 1 through 100 will make the variable $i start at one and go up to 100. Here we used the nth-child pseudo selector with the looping $i variable to set the background-color for each div.
To make this actually do what we want, we’ll use the darken() function, and set it’s percent variable to the $i, which will increase for each block. Fun fact: Sass will automatically use a keyword rather than the hex code if there is one.
We can also do each loops, which do loops over lists. Start by writing @each, then a variable, then in, then the list, then code you want in curly brackets.
Advanced Mixin Arguments
Here, we’ll rewrite the @each loop from the last lesson as a mixin. We’ll start by making a mixin, naming it band, and pasting in the each loop. Then, we’ll include it to make sure it shows up in the css. Remember, a mixin doesn’t do anything until you include it.
But this isn’t dynamic. We want to be able to pass in arguments. Here’s one way to do that.
But, if we want to include a second band with only one member, it gives us an error, because it’s expecting four.
To fix this, mixins accept variable arguments, meaning anywhere from 1 to infinity. To do this, you simply write an argument followed by three dots. Here we changed the argument to that, then changed the list in the each loop to the new argument, minus the dots.
Let’s go a step further and have it accept the name of the band as well. We added a second argument, $name, and used that to change the class name and folder path for the background image as well.
In Sass, there are lists. In the example below, the margin values are separated by spaces and count as one list value, made up of the four margins. If you added commas, then it would be wrong and they would each become a separate value.
So, for our previous example, if we remove the three dots from $members, we can actually list the members without commas, as you can see in the first include here.
Still, this really isn’t recommended, as most other programming languages don’t have a concept like this.
Here, we start with a pretty straightforward mixin.
But, users may get confused on the order they need to pop in the arguments (which matters). As a way around this, you can actually write the $variable_name: value instead of just the value. This makes it so the order you write in the arguments doesn’t matter, which is helpful if you have a lot of options.
If you do this when writing the mixin itself, you can actually set a default value. Here, display will default to block unless otherwise specified. We didn’t even have to provide a value for $display when entering the arguments without their name.
If you set a default for every argument, you actually wouldn’t even need to pass in any arguments if you’re okay with just the default values.