I recently had the opportunity to teach HTML and CSS to a class of women through Chicago Women Developers, an organization devoted to the advancement of women in tech. As a part of that course, we covered Sass: a CSS extension language that makes stylesheets easier to read and use for developers, then converts into plain CSS for the browser to read at runtime.
In order to demonstrate how Sass works, I showed the class a few examples of the language in Sassmeister, which does the Sass-to-CSS conversion before your eyes. Then I took screenshots! Though we didn’t cover all of Sass, we did cover several well-loved staples. Here are demonstrations of my five favorite Sass functionalities, in ascending order:
There are several hallmarks of excellent code. One of them is that the code clearly indicates intent. However, When you look inside a plain CSS stylesheet at screen widths and box sizes, all you see is a number. Why did the designer or developer choose that number? S ometimes it doesn’t matter (I like 24 point font, and I’m the expert, capiche?), but sometimes it does: say, if Developer A chose a specific size to conform to a desktop computer screen width, and now Developer B is responsible for creating the iPad app. One could leave a comment in CSS for questions like these, but in Sass, we’re allowed to show our work:
This is much clearer, no comments necessary!
In Sass, I can make a basic template for objects that are structurally or stylistically similar, then have the styles of each of those objects @extend my basic template, plus their own custom styling. Think of it as inheritance for stylesheets. Like so:
This creates a basic template for the styling of some pop-up messages, then styles each of the pop-up messages according to what kind of pop-up message it is.
@mixin, like @extend, allow me to create a group of style choices with the marker @mixin, then stick them into any other style definition with the marker @include. There are two examples below: one, called website-theme, that defines some basic styling to apply to several pieces of a website (but perhaps not all—thus why we have not just applied these styles to some kind of all-encompassing div).
The other one, called border-radius, accepts an argument—the argument $radius. This mixin exemplifies a way to easily package up cross-browser compatibility in your styling when different browsers each have their own tags for the same thing (as is the case with border-radius). In this example, I set the $radius to be the same across all browsers: if, for some reason, you wanted them each to have different border-radii based on some initial number, you could combine the power of mixin arguments with the power of explicit math to do that in your mixin.
Below, you can see a demonstration of using the same mixin with a different argument passed in:
It works exactly the way it looks like it should work. This, in the software world, is a very good thing.
2. Nested Styling
When I have a lot of styles that apply to the same unit of visual information on my website, I want them to appear in a unit in my stylesheet as well. So, when I have several elements inside, say my navbar, and I want to style them all specifically for my navbar, I can organize them in Sass by nesting them:
Perhaps this feature also appeals to the backend developer in me: it DRYs up the code by removing the repetition of .nav in the CSS.
The trick that we used above to create a variable in a mixin is also available throughout a Sass document:
To make a variable in Sass, you put a $ at the front of the word.
The reasons you would want variables in a stylesheet are exactly the same reason you would want variables in any computery language: they reduce duplication in the code. They allow you to more clearly express that the #F5F5F5 that currently graces several spots in your css is actually your chosen $textbox-background-color, and you can change all those textbox backgrounds in one place by changing the variable declaration.
In fact, given that variables are one of the first things you learn in almost any computery language, one is forced to wonder why stylesheets didn’t already have them. But now they can, thanks to Sass and other language extensions like Sass (LESS comes to mind, though I have never used that).