How Sass Can be Used for Responsive Development

Let’s jump right in and have a look at some typical Sass code. Observe how it looks like CSS combined with some of the variables and math that you might recognize from a programming language such as JavaScript. Web browsers can’t read this file, but instead, the Sass tool reads this and writes out plain old CSS. Software engineers call this type of tool a preprocessor. A tool reads in Sass files and outputs CSS. We might refer to Sass as a metalanguage because it embraces CSS while extending it into far-reaching paths.

Sass starts building on what you know about CSS, slightly shifting your expectations in a dozen different ways. Putting together their amazing combinations empowers you to craft websites better than ever before. Diving into Sass can start simply for you because it’s compatible with CSS. Looking into Sass, you can pull that one thing that makes you curious and solves a distinct problem you encounter daily. Use that thing often, and as your skill increases, your confidence will increase as well. Then reach for the next feature and bring it into your creative workflow as a turbo boost. This chapter is dedicated to introducing artists and designers to some of the most practical parts of Sass.

Creative leaders may want to tag a curious individual on your team to go off and experiment with Sass for a few days or for a few hours a day for a week. Let them explore how many aspects of it will help your team and come back with a brief show-and-tell over lunch. Let it be informal, but purposefully dedicate time to it with all your people present and receptive toward learning from the sharing. See if the lesson helps your team move forward with increased capacity. Use this chapter to guide your forward-thinking adventurer while learning about this intriguing technology.

CSS is Difficult to Write and Maintain

CSS is a programming language. Writing it is super simple—you do it all day long. Writing good CSS is crazy hard. If you’ve ever tried to make big sweeping changes across an existing CSS codebase, you know how tricky and unmanageable bad CSS can be. Our goal is to write clean-looking CSS that’s easy to read and update. This is a challenge. Not impossible, but surely complicated, because as a programming language, CSS offers no formal opinions on organization—at least not to the extent I expect to see given my career as a software engineer.

Because I’ve been programming for a little more than 30 years now, more than some of my teammates have been alive, I have expectations from the languages I choose to use for solving interesting problems. Exactly what qualities have I come to expect from a programming language? Here are some of the high-level qualities missing from CSS that I’ve come to expect:

• Hierarchy— things relate to other things, and it’s good to declare that with left-aligned whitespace, for example, showing dependent “children” inside owning “parents”
• Encapsulation— don’t let code logic and data settings escape from a thing by leaking out into the global space occupied by other things that are completely unrelated and don’t care
• Composition— make up new things by building them up from working parts and reliable pieces pulled from other successfully constructed things

I’ve found that when programming languages have these ideals built into their syntax and way of thinking, it makes my job easier and raises my chance of success. Can a team of A players do a perfectly fine job crafting a portion of their project using plain CSS even though it lacks those features? I must answer yes because I’m a tireless optimist and have seen the power of creative and skilled people overcome barriers in the face of constraint. I’ve seen it happen on many occasions in my career, and joining up with teams of these high-quality individuals is my great joy.

What if that team of highly skilled, engaged, and dedicated individuals is tired and stressed out from trying to meet aggressive deadlines? What if that teams in fact has a number of rookie members learning how to build and deliver? In that case, CSS’s lack of core features for building software in a professional manner hurts. It’s all right, because there’s good news: Sass exists to help us overcome CSS’s weaknesses.

Variables

Engineers use variables to hold a value like a number, color, word, or sentence. Naming things is often difficult, but assigning a number or string of letters to descriptive variables tells the reader what the number or color or string does or why it exists. CSS forces us to type font sizes and colors over and over again in our style definitions. Variables start with the $ character followed by letters or numbers that make up the name.

What if you use a particular color a dozen times and it changes due to a branding update? It’s a chore seeking and finding all of the places the old value is used to update it. Tedious work certainly brings with it the potential for creating bugs due to human error in completing the mundane task. Putting colors, sizes, and strings in variables helps isolate the values to a single, well-known place. Updates, maintenance, and routine polish ought to be easier in the future or as initial launch development races along. Here’s an example of this concept.

Importing/Partials

Breaking big problems into smaller ones often leads to success more quickly. Think of how you probably have many .html and .js files in your website. Sass lets you break down a single .CSS into many .SCSS files. Engineers strive to organize their source code in this way, referring to a concept known as single responsibility principle. That concept suggests one file (module or library) does one thing very well. Sass calls a .SCSS file that handles a particular part of your overall style rules a partial. Start a .SCSS filename with an underscore, and Sass will treat it only as a file another one depends upon and imports. Sass files that don’t start with an underscore could be compiled into their own .CSS, and that might be wrong for your needs.

Sass extends the CSS @import command, allowing you to bring in any number of files, or partials, into a main .SCSS file. Ideally you’ll plan these well, allowing you to build them once and use them throughout your company on many websites. The concept of reuse is a powerful one, as your hard work on one project turbo boosts others. Here’s an example of how a main file might look:

While reading this code snippet, please realize that the Sass tool will look for and find files named like this: _reset.scss and _grid.scss that match what is written above. When your Sass is processed, consisting of a collection of one or more .SCSS files, it creates a .CSS file containing all the style rules made ready for a web browser to read and render. The Sass tool has an output style parameter that tells it how to format the CSS. Using the compressed style saves as much space as possible, making it nearly impossible for a human to read but making it as efficient as possible for quickly transmitting from your web server to your customer. Efficient file transfer is important because most people have a data plan with their cell services, and conserving their data budget whenever feasible is the best choice. Not to mention quick load time means more satisfied customers.

Nesting/Hierarchy

Engineers like hierarchy. Entire ideas such as object-oriented programming are based around the concept of hierarchy. In design, composition is how visual relationships are shown. Sass offers nesting as a way of writing code with hierarchy and showing relation. Tucking away styles inside other ones with indenting lets us more easily communicate those tricky relationships to other human beings. Others could be teammates or our future selves who have long forgotten code we wrote.

One of the aspirations is ensuring this code looks as rational as possible. Our goal should be writing source code that provides the entire context and meaning a skilled reader needs to understand what the author intended.

Here’s another example with special notation. Notice the ampersand (&) symbol starting the :hover and :active rules. The ampersand is simply a reference to the parent selector. Using it keeps the Sass code clean and concise looking.

Math

As an author of CSS, you know lots of numbers are floating around your code. Sizes could be in pixels, offsets in percentages, and colors in hex. Numbers are made for math, and Sass helps you perform math in your CSS. Add, subtract, divide, and multiply are available.

Why would you want to do math in the middle of styles? Think about design being about composition and visual relationships between elements. One rule could have a property 25% bigger than another, or starting height with extra pixels added.

Another simple case is bumping over a group of elements by a few pixels. During a polish pass, you could quickly adjust the right or left attributes by typing +6, then +23, and then +38, working elements around the page while refreshing your browser and watching the results. Once satisfied with your fine-tuning, add up the numbers and keep the final ones.

Functions

Sass offers a collection of functions for processing numbers. Functions are more complex than the common math operations because they cover a range of needs but ought to be relatable because they’re practical. Ultimately, they solve design problems and that makes them concrete and real. For example, use a Sass-provided function called darken to tweak a base color for a bottom-edge shadow:

Look through the Sass documentation for more on using this function. Review all the others they have. Many more exist for tweaking colors, changing text, processing numbers, and operating on sets of data.

Again, start with a few things that make sense to you because they solve a problem you have. Use a few until you gain complete confidence. Then reach for a few more and incorporate them into your workflow. Keep the things that work and replace those that don’t.

Media Queries

Responsive web development demands use of media queries for influencing how HTML tags are rendered by their applied styles. Sass helps organize media queries by tucking them underneath their tags and classes. This makes code look more beautiful because it’s organized and rational looking. The left-hand spacing that pushes rules to the right lets you clearly see relationships. Mindful organization from the start of a project always makes jobs go better and sets everyone up for success into future maintenance. You’ll notice this is another example of nesting that the Sass tool provides.

Here’s an example of a style rule written in Sass that shows two media query rules for a tag with a specific identity. The first shows it at a smaller size for a phone. The second gives it a larger size for tablets. Notice how the code is self-documenting, with the use of variables instead of hard-coded numbers. As opposed to using a pixel number in the media query, it assigns the number to a well-named variable. The clear variable name describes what it is and shows why it’s used.

Mixins

Inventing software tools is fantastic because they’re infinitely available. No need to reinvent the wheel, as the cliché goes. CSS offers very little support for building tools, and it seems as though cut and paste is the single way to work faster. Engineers have learned the problems with cut and paste. The worst is when changes are needed. How does a teammate update a block of code when it appears six times? By searching for it and changing each one, and if one is missed, it produces a bug. This tactic is error prone because humans get bored with this type of chore. What if you’re not entirely sure how many times a block of code was duplicated and across how many files? That’s an error-prone situation as well. What if a copied block was changed a little bit, making it look different enough to make a teammate doubt whether they ought to make a change?

Sass has the perfect way to reuse a snippet of CSS source code. Once you’ve crafted your code, wrap it up into a mixin. Use it over and over again throughout your .SCSS files. Mixins are referenced wherever you want the associated CSS to expand into place. Some good examples for writing a mixin include:

• Vendor prefixes for an emerging CSS standard such as CSS3 rounded borders or upcoming animation support
• Visual design from a style guide
• Often-used hacks such as a clearfix routine

Defining and using a mixin looks like this:

Although the mixin uses a few hard-coded numbers rather than well-named variables for the padding and font size, the fact that they’re contained within the mixin helps hide them away from spilling out into the file. Anytime that mixin is changed, simply running the Sass tool on your .SCSS files guarantees updates are distributed throughout your project wherever the mixin is included. No need to guess where they are. That might not seem important as a project begins because it’s fresh in your mind and you can flip to references quickly. As time goes on, however, a team’s collective memory becomes fuzzy, and letting Sass help is an advantage. No need to search and replace throughout a collection of code files, since a quick run of the tool rebuilds your .CSS file.

Compression

As an engineer, I talk and debate about compression at least once a week. I believe everything can be made smaller. Smaller is nearly always better when it comes to modern electronics and nearly always better when applied to resources sent from your web server to your customer’s device. Images can be compressed, JavaScript can be compressed, and so too can .CSS files. Sass has you covered in this category because the .SCSS files can be written out to a final combined file written as small as possible. It does that by throwing away as much white space as possible. Humans benefit from spaces and line breaks when reading, but web browsers simply don’t care and read it without hesitation.

Sass writes out your combined .CSS file in what it calls the output style. Without telling it anything special, it writes a file with whitespace and line breaks making it human readable, and the largest possible. For example, given this typical media query snippet, which is easily read by any human teammate and is uncompressed, weighing in at 320 bytes in size:

Compiling it to a default .CSS file, you’ll see written out code that’s 226 bytes long and looks like this:

The same code written out with compressed style produces a .CSS file only 185 bytes long that looks like this:

The difference in file compression is almost a 20% saving, and believe me, it adds up over time. Your project’s SCSS source code and final CSS are going to be much larger than this elementary example. The more readers that visit your site, the more bandwidth cost you save on sending files to them. It’s a win all around, and Sass builds this in from the start.

Modern Comments

I believe that commenting code can be a weakness. Many people say it is a strength because an author is conveying meaning to future readers. But comments are just another way human beings create bugs. An author tells why they’re doing something because the code tells what is being done. Later maintainers end up inserting code, shifting lines up and down, and retrofitting new features. If they didn’t maintain the comments as well, then they’re all out of date and obsolete. Worse, they’re outright incorrect or possibly even near the wrong lines of code.

The next time you write code and feel the need to add comments to explain what is going on, take a moment and consider if the code can be rewritten in a way that doesn’t require a comment. Usually the second pass will be better designed.

Modern code writers understand it’s best to write code that’s self-documenting. That said, Sass offers modern comments that look like // rather than /* */. The double-slash syntax for comments is easier to type, less error prone, and looks far less noisy when reading through source code. Here’s an example of modern comments.

Let Sass Help

Sass is a tool built to help you. By layering up a level of syntactic sweetness, it improves the restrictive yet verbose CSS we all started learning years ago. You might discover using the Sass tool is confusing every once in a while. Command-line tools generally receive a negative opinion because they seem to hide their functionality. There are no menus or buttons that obviously reveal their abilities, as a GUI app has. Convention among engineers is making their command-line tools accept the parameter ––help to offer up reminders. When you issue the command sass ––help, you’ll see a block of text reminding you what the Sass tool can do given parameters. Take advantage of this help while learning the tool to start and periodically as you reach for one of its extended capabilities.

Installing Sass

You’ll want to install Sass once you’ve read through this chapter and decided that it’s a powerful tool to add to your professional toolbox. Look to the official website for how to install it:

The Sass site describes two ways of installing Sass: (1) using a GUI app and (2) using the command-line tools. The GUI apps are actually calling the Sass command-line tool behind the scenes. Some are free and others are paid, and all come from third parties building atop Sass. Please pursue one of them if that feels more comfortable to you.

The command-line tool is what is officially supported by the community that builds and improves Sass. Because they are building the command-line edition it will have the most up-to-date improvements first, and apps will try following up behind them. I recommend you install and use the command-line version. Many people think the command line is intimidating because it doesn’t casually reveal its capabilities. Look to the Sass documentation on their website, because it reveals all. This chapter has a section showing how to use Sass well enough to propel you through your work.

When you look at their installation website, you’ll see a list of apps you can choose. Some run on one or more of the major operating systems. The command-line edition asks for you to first install the programming language Ruby. If you’re using a Mac, congrats, you already have Ruby because it comes preinstalled in OS X.

Please follow the Sass website instructions for installing their tool. I believe they’re clearly written and current. There’s no need for this book to duplicate their fine effort.

Programmers Have (Code) Style

Why does code style matter? Do you need to settle on a convention? Probably not if it’s just you writing Sass by yourself. As soon as you mix in other folks, it has a way of becoming more difficult than we want it to. Modern web development is already complicated enough that figuring out the ways of making it simpler ought to be a goal. A key way engineers have found is agreeing on conventions in code style.

If everyone on the team is writing code that looks the same, at least you have that going for you when everything else is getting tough. When all the Sass code looks the same, at least that feels welcoming and consistent when you drop into a file someone else wrote and intend to edit it. Any project of a significant size on any project running a significant time will have a lot of code. Odds are lots of it won’t have been originally crafted by your hand, but you will eventually touch it.

What goes into a code convention? Mindfully making choices like these:

• Indents as spaces or tabs
• How to name variables camelCase or snake_case or divided-by-dashes
• The order of attributes in a style definition
• Hierarchy of files and how you break down into files (includes)
• Any external libraries that you want to pull into your project
• How much you abbreviate variable names

Use code reviews to enforce and remind one another about convention details. Use this as a way to initiate new teammates. Teach them by having them look at the best code you’ve written and fix the worst of it. By the way, all the code ought to be good enough that you’re proud to show off it.

Code conventions are similar to design guides. Typical of most art departments, guides keep teams on track, build capacity, and retain consistency among employees. You’ll find this even more valuable if you ever need to work with external contractors to help build some of your site. They might have their own style or a complete lack of style, and you’ll want them to conform to yours. Some of it is for looks, but it’s defensive, too. Have high expectations in quality early and throughout your project.

Craft your own code style guide. Encourage everyone to add to it and improve it over time. Keep it alive, and change it in response to what you’ve learned. Start with a community-published guide if you don’t want to write one. Search on you favorite search site, and you’ll find several from which to choose. Pull in the one that strikes you and work from it for a while. Learn what you like and dislike about it and improve it as you work.

Whatever you do, please make a decision as early as possible. You have a choice, and it matters. CSS is one of those things that gets out of control quickly. Sass absorbs some of those troubles, but it can’t protect you from everything. In an organization big enough to have multiple teams, they might all want to have a choice in picking their convention, but caution against that. Creative leaders might want consistency across teams and their assigned projects, just as a team would among its members. This might make it easier for employees to cross boundaries and slide between teams. Then they can help when deadlines get crunchy and have an option when they crave a new creative outlet and desire to transfer inside the company.

Sass makes you choose from one of its styles. Look at their website, and you’ll see code examples are shown using two distinct syntaxes. One is SCSS, and it is the style I’ve chosen to write examples in. It borrows heavily from the basic CSS syntax and looks familiar to anyone writing CSS code. Because of the familiar feel, I suggest that you adopt it.

The second syntax choice is called Sass. It offers minimalism by removing most punctuation for clean-looking code. Indentation beginning each line is important because it describes hierarchy and context. It’s a more radical interpretation of CSS, and if your team selects it, there will be a learning curve.

Debugging Sass in Chrome Developer Tools

Finding glitches and fixing them is a recurring theme in this book. A key ability of debugging your code is seeing your source code executing in a browser. When you get to a problem, you can page through your code and see the state of affairs of your program. Browsers know about HTML, JavaScript, and CSS. CSS is naturally the final output of your Sass, but seeing what the CSS looks like in your browser as you step through code isn’t the best possible way to diagnose logic errors. When you get to a point where you’re writing Sass daily, you’ll want to debug within the context of it.

Google’s Chrome browser has a working solution for this. It connects the dots between the written CSS output and the original Sass you wrote. A technology called “source map” is what you’ll see written when you investigate this topic.

Because this is an advanced lesson, we won’t review details about it in this book. It’s more than I want to get into now, but please research this tool when you’re ready to learn about it. Check out this page for more:

Community Tools

Libraries are bundles of code that are easily used in present and future projects by you and your team. Lots can be made of them, but in the end, they represent solutions for problems you’ve already faced and ought to never have to repeat. Whenever possible, think of building up libraries, because the time invested in crafting them now will make working in the future quicker.

The open-source community has assembled many libraries that you can reach for. Like any tool, they amplify your abilities and empower you to better perform your job. I see the additional tools supplementing Sass in two distinct ways:

1. Applications providing graphical user interfaces
2. Frameworks of styles and functions

The Sass install page lists a number of applications that you might prefer over the command-line interface. Here are examples of some of the libraries that provide solutions to responsive design, grid layouts, browser-specific vendor prefixes, animations, and other helpers: Compass, Foundation, Bourbon, Neat, Susy, and Bootstrap.

By now you’ve looked for solutions to your project glitches and problems using your web search engine of choice. It’s good to remember this is an alternative when you and your team-mates are stuck trying to solve a problem. There’s a good chance someone else has had a similar glitch, fixed it, and documented the solution. Even better, these folks might have productized the fix by publishing a library and posting it on GitHub. Take advantage of prior art if you can, and participate in it by publishing some yourself.