Sass and Compass Designer's Cookbook

You can install Sass on Linux, Mac, and Windows. Sass has been written in Ruby. So, installing Sass requires that you install Ruby first. Ruby is a dynamic open source programming language with its focus on simplicity and productivity. You can read more about Ruby in the Ruby and MongoDB Web Development Beginner's Guide book by Gautam Rege. You will find this book at https://www.packtpub.com/web-development/ruby-and-mongodb-web-development-beginners-guide. If you are using Mac, you are lucky because OS X has Ruby preinstalled. Linux users should use a packages manager, such as Advanced Package Tool (APT), to install Ruby:

 sudo apt-get install ruby-full

Other methods to install Ruby on Linux can be found at https://www.ruby-lang.org/en/documentation/installation/.

Finally, if you are on Windows, RubyInstaller is available. RubyInstaller is a single-click installer that includes the Ruby language, an execution environment, important documentations, and more. You can find RubyInstaller at http://rubyinstaller.org/.

After installing Ruby, you can use the following steps to install Sass on your system:

RubyGems is Ruby's package manager. Ruby packages, called gems, can easily be installed via the command line and be distributed over the Internet. Many gems are hosted at https://rubygems.org/ and https://github.com/. Also, Sass is distributed as a gem. The Sass gem will not only install Sass, but also install all the dependencies for you. Installing Sass with RubyGems will be easy and straightforward.

The gem install sass command in this recipe should install Ruby Sass and all its dependencies.

After installing Sass, you can use the --help option to get a list of the available options and a short instruction on how to use the command-line compiler:

sass --h+elp

Besides the Sass compiler tool, the Ruby Sass gem also installs the sass-convert command-line tool. The sass-convert tool can be used to convert files from the indented syntax into the newer SCSS syntax and vice versa. Notice that you can also use sass-convert to migrate the CSS code Sass or the SCSS code. This will give you some basic nesting when migrating your CSS code.

In the Writing Sass or SCSS recipe of this chapter, you can read about the differences between the original indented syntax and the newer SCSS syntax.

The Ruby on rails apps can also use the Ruby Sass gem to compile the CSS code. Read more about Ruby on rails and Sass in Chapter 14, Ruby on Rails and Sass, of this book.

You will have to install Ruby before installing Compass. In the Installing Sass for command line usage recipe of this chapter, you can read how to install Ruby on your system. Both Compass and Ruby run on Linux, OS X, and Windows. When you install Compass before you have installed Sass, Sass will be installed automatically, since Ruby Sass is a dependency of Compass.

After installing Ruby, you simply have to run the following command in your console to install Compass:

gem install compass

That's all. You can also try the following steps to get a short impression of how to run Compass on the command line:

The config.rb file contains the configuration for your Compass project. This file is well-commented, and it contains, among others, the path to your project's folders.

Running the compile project command compiles each Sass file from the Sass (sass_dir) folder into a CSS file in the stylesheets (css_dir) folder. Files having a name starting with an underscore (_) are called partials and are not compiled into a CSS file. You can read more about partials and how to use them in the Working with partials recipe of this chapter.

You can also directly use the features, mixins, and helper functions of Compass together with the command-line Sass compiler (see the Using Sass on the command line recipe of this chapter) by setting the --compass option. For more information on integrating compass in your compile process, you can read Chapter 6, Using Compass.

Compass is a widely used Sass framework. Many other frameworks for Sass are available too. Susy is a powerful set of Sass mixins for building grid-based layouts. Susy was originally built to be a part of the Compass ecosystem. In Chapter 9, Building grid-based layouts with Sass, and Chapter 10, Susy and Sass, of this book, you can read about Susy. And in Chapter 13, Meeting the Bourbon Family, of this book you will be acquainted with Bourbon. Bourbon is another library of Sass mixins.

This recipe demonstrates how to set up a project with only Compass. In the Adding Compass to an existing Sass project recipe of Chapter 6, Using Compass, you can read how to integrate Compass into existing projects too.

The official website for the Compass framework can be found at http://compass-style.org/.

In the Installing Sass for command line usage recipe of this chapter, you have already read how to install Sass. Linux users have to open a terminal, while Mac users have to run the Terminal.app, and Window users have to use the cmd command for command-line usage.

Use the following steps to find out how to compile your Sass code in the command line:

Firstly, notice that the example code in this recipe uses the newer SCSS syntax for Sass. In the Writing Sass or SCSS recipe of this chapter, you can read why this book uses the SCSS syntax in favor of the original indented Sass syntax.

The sass command directly outputs the compiled CSS code to your console. To save the output in a file, you will have to set a second output argument, as follows:

sass first.scss first.css

The preceding command creates a new first.css CSS file that contains the compiled CSS code.

When compiling your Sass templates into CSS files, Sass does not only create CSS files, but also a folder called .sass-cache. By default, Sass caches compile templates and partials. In the Working with partials recipe of this chapter, you can read what partials are. Caching of the compiled templates and partials makes recompiling after your changes faster.

You can use the --no-cache option to disable caching.

The --compass option makes Compass imports available and loads the project's configuration. You can read more about this option in the Extending Sass with Compass helper functions and more recipe of Chapter 6, Using Compass.

The interactive mode of Sass comes with the Sass gem. You can use it after installing Sass. In the Installing Sass for command line usage recipe of this chapter, you can read how to install Sass.

Take a look at the following steps to understand how to use the Sass interactive mode:

As it has already been made clear in the introduction of this recipe, you can use the interactive shell to test the property values set by SassScript. The interactive shell does not allow you to use variables or mixins, but you can make use of Sass's built-in functions. Chapter 5, Built-in Functions, of this book will introduce you to the useful built-in functions of Sass. The function used in the fourth step of this recipe is an example of a built-in function.

To quit once you have entered the interactive mode, just type Ctrl + D.

The Compass gem has an interactive shell that is available too. You can start Compass's interactive shell by running the following command in your console:

compass interactive

In the interactive shell, you can run SassScript and you can also test the results of the Compass helper functions. Try the following command to evaluate the append-selector() helper function:

>> append-selector("p, div, span", ".bar")

The preceding command will give the following output:

"p.bar, div.bar, span.bar"

In your Sass code, you should use the preceding result inside an interpolation escape: #{ }.

To use gulp-sass (uses node-sass), you should install Node.js (npm) and Gulp on your system first. Node.js is a platform built on Chrome's JavaScript runtime to easily build fast, scalable network applications. Gulp is a task runner or a build system written for Node.

You also have to install gulp-sass by running the following command in your console:

npm install gulp-sass

The following step will show you how to use Gulp and gulp-sass to compile your Sass code into CSS code:

The gulp-sass plugin is a plugin for Gulp that enables you to compile your Sass code with node-sass. node-sass is the node interpreter for LibSass.

As it has been already explained, Gulp is a task runner. The Gulpfile.js file defines the task. This file has been written in the JSON format.

The gulp.src ('./sass/*.scss') code reads all the files with the .scss extension from the sass folder. The content of each file is compiled with the sass() command from the gulp-sass plugin. And the compiled CSS will finally be saved in the folder set by gulp.dest().

Each SCSS file will be compiled in a new CSS file, but notice that the partial files (see the Working with partials recipe of this chapter) are ignored.

Gulp is just like Grunt—a task runner for node. Grunt does not use streams like Gulp, but saves results directly in files. Grunt has a longer history and a big community too. On the other hand, people find streams (saving file contents in memory) more intuitive and the number of Gulp plugins grows fast. In this book, Gulp is used for setting up build chains without saying that it's better than Grunt or any other task runner. Bootstrap, as discussed in Chapter 12, Bootstrap and Sass, of this book, uses Grunt, while Foundation uses Gulp. You can read more about Foundation in Chapter 11, Foundation and Sass. You can read more about Grunt in Chapter 16, Setting up a Build Chain with Grunt, of this book.

Also, a gulp version for Ruby Sass is available at https://github.com/sindresorhus/gulp-ruby-sass. In the past, the Sass Ruby gem was leading in regards to developing new features. Because LibSass was not directly updated after the releases of Ruby Sass, there were differences between Ruby Sass and LibSass. Recently, LibSass has become part of the Sass community, and Ruby Sass and LibSass are maintained at the same speed as much as possible. Some minor differences between both the versions can be found, but Ruby Sass will usually wait for feature parity with LibSass.

Bower is a package manager for the web-optimized for the frontend. You can install bower by running the following command:

npm install - bower

You can run the following command to install sass.js and jQuery:

bower install sass.js jquery

After installing sass.js, you will need a text editor to edit the HTML file and a browser to inspect the results. You can also find the source code of this recipe in the downloaded files of this book.

Here is how you can compile Sass code in your browser:

Every time you hit the submit button, the sass.js compiler will compile the following code:

$color: {color};
h1 { color: $color; }

With {color} depending on your input, your input should be a valid color name. The 147 color names defined by the Scalable Vector Graphics (SVG) are according to their specifications used by HTML and CSS3 too. See also http://www.w3.org/TR/css3-color/. You can use any valid CSS color value in Sass, so rgb(0,255,255) or even rgba(0,255,255,0.5) can be used too. You can read more about color usage in Sass in the Color functions recipe of Chapter 5, Built-In Functions.

The demo uses jQuery to insert the compiled CSS into the DOM (in line with the tag of the head section). jQuery is a feature-rich JavaScript library that can be used for HTML document traversal and manipulation, and event handling. Neither Sass nor sass.js requires jQuery for compiling.

In the Editing and debugging your Sass code in browser recipe of Chapter 2, Debugging Your Code, you can read how to debug your Sass code in a browser using the Google Chrome browser. Although the code of this recipe runs in a browser, the sass.js compiler is not used here. In browsers, debugging uses the Ruby Sass compiler with the watch function or LibSass with live reload.

As it has already been made clear, you should not use sass.js for production in the first place. When you use Sass for a demo proposal as in this recipe, and you need to compile Sass based on user input, you can reduce the total load time leveraging a web worker. A web worker is a JavaScript that runs in the background, independently of other scripts. Sass.js ships with a web worker, which can be invoked as follows:

<script src="dist/sass.js"></script>
<script>
  // telling sass.js where it can find the worker,
  // url is relative to document.URL
  Sass.initialize('dist/sass.worker.js');

Because sass.js runs in a browser and does not have access to your files' system, you should register individual files before using them with the @import directive. The following is an example code that shows you how to register files:

Sass.writeFile('one.scss', '.one { width: 123px; }');
Sass.writeFile('some-dir/two.scss', '.two { width: 123px; }');
Sass.compile('@import "one"; @import "some-dir/two";', function(result) {
  console.log(result.text);l
  });

For this recipe, you will need only a text editor and the Ruby Sass gem installed. In the Installing Sass for command line usage recipe of this chapter, you can read about how to install the Ruby Sass gem.

Use the following steps to learn how to convert SCSS code into the indented Sass syntax and find out that both syntaxes compile in exactly the same CSS code:

Currently, two syntaxes are available to write Sass: the original indented syntax, mostly called Sass, and also the newer Sassy CSS (SCSS) syntax, which is an extension of CSS3.

When running the sass test.sass and the sass test.scss commands, the compiler uses the file extension to decide which syntax should be used. In your project, you can import partials in either syntax without any problem. Again, the compiler knows what to compile based on the file's extension. In the Working with partials recipe of this chapter, partials are discussed in more detail.

The sass-convert command-line tool used in this recipe ships with the Ruby Sass gem. After installing the gem, you can directly run the sass-convert command. This command looks at the file extensions too; .sass is converted into .scss or vice versa.

As you already know, Sass has been written in Ruby. Ruby is the programming language. You can also use Ruby with Ruby on Rails. Ruby on rails is the Ruby framework for creating web apps. Ruby uses both Sass and HAML. HAML is a markup language used to clearly and simply describe the HTML of any web document without the use of inline code. HAML is a template system for HTML that tries to avoid repetition of code and unnecessary characters by relying on indentation and not the text to determine where the elements and blocks of code begin and end.

The original Sass syntax used the same method of declaration and coding that Ruby does and relies on indentation, as HAML does. This syntax is an excellent fit in Ruby (on rails) and feels already familiar for Ruby developers.

The newer SCSS focuses on the proposal of Sass in being an extension of CSS. Not only does SCSS look like CSS, but any valid CSS code is valid SCSS code too. Because this book is not only intended for Ruby developers, but for anyone who wants to learn Sass, this book uses the newer SCSS syntax for Sass.

You should have the Ruby Sass command line ready, as described in the Installing Sass for command line usage recipe of this chapter. You will also need a text editor.

Perform the following step to see the differences between the Sass output styles:

Sass enables you to choose your output style by setting the --style command-line flag. In this recipe, you have seen the different output styles of Sass. The first expanded style produces CSS code formatted in a manner that would allow you to write it yourself when directly coding your CSS code. In fact, the output has not got any special syntax or format.

The second and default style you have tried is the nested style. In the Using nested selectors recipe of Chapter 4, Nested Selectors and Modular CSS, you can read about the ability of nesting selectors in Sass. The nested style makes the nesting of selectors in your Sass code visible in the compiled CSS code by adding additional indents before the selectors that are nested. Notice that the real nesting of selectors is not possible in a valid CSS code, so the selectors are not nested in the compiled CSS. Because the indent helps reflect the structure of the CSS styles and the HTML document, it will make your code more readable and easier to debug. In Chapter 2, Debugging Your Code, of this book, you can read more about testing and debugging your Sass and compiled CSS code.

Finally, the compact and compressed output styles reduce the file size of the compiled CSS code. The fewer the number of bytes of the CSS code to download, the faster your website or app will load, which improves user experience too. The compact output style reduces the number of white space by not having nesting and each selector on a single line, while the compressed output style only has minimal white spaces required to meet the CSS specification. When using the compressed output style, the compiled CSS code has no whitespace except that necessary to separate selectors and a newline at the end of the file.

The compact output style and especially the compressed output styles are not intended to be read by humans. In most situations, you will use the default nested output style for the development stage of your project. When taking your project into production, you should compile your CSS code with the compressed output style. When you are using CSS source maps to debug your code, as described in the Using CSS source maps to debug your code recipe of Chapter 2, Debugging Your Code, your output style for the development stage does not matter.

The compressed output styles also remove all your comments. You can read how to comment your code and which comments are preserved in the Commenting your code in SCSS syntax recipe of Chapter 2, Debugging Your Code.

When using Compass, as described in Chapter 6, Using Compass, of this book, to compile your Sass code, you can choose the same output styles as described in the previous section. Output styles are set in the config.rb file of your Compass project. When not explicitly setting the environment option to production, Compass uses the expanded output style. In the production environment the compressed output style had been used.

You have already read that the compressed output style removes all the extra white space. Also, colors are converted to their shortest notation. Further optimization of your CSS code is possible, but it is not a task for Sass. Postprocessors, such as clean-css, also perform a more advanced optimization of your CSS code like selector, property, and media query merging. In the Automatically prefixing your code with Grunt recipe of Chapter 16, Setting up a Build Chain with Grunt, you can read about how to integrate the clean-css plugin and other postprocessors into your build chain.

You can find the clean-css CSS minifier for node.js at https://github.com/jakubpawlowicz/clean-css.

This recipe requires the Compass installed as described in the Installing Compass recipe of this chapter. You can edit the Sass code in your favorite text editor.

The steps beneath will show you that partial file are not compiled into the CSS code:

Sass files beginning with an underscore are called partials and won't be compiled to CSS, but they can be imported into other Sass stylesheets. Partials are useful for modularizing your code. When you split up your code into different files based on the type of function, you can easily reuse your code. When you modularize your code and use a file's structure with partials that reflects the modularization strategy, it will also be a lot of easier to find the needed code when you have to maintain your applications.

In this recipe, the partial has been imported with the @import directive; you can read more about this directive in the Importing and organizing your files recipe of Chapter 9, Building Layouts with Sass. Compass compiles all the files in the Sass folder, but ignores partial files starting with an underscore (_). When compiling your code with node-sass, as described in the Using the sass-gulp plugin with Gulp recipe of this chapter, files starting with an underscore are also ignored by default.

When you compile your project on the command line, you mostly automatically compile only the main file, as the command line compiler only accepts a single input file.

Also, the @extend directive possibly requires some more detailed explanation. You can learn more about the @extend directive in the Utilizing the @extend directive recipe of Chapter 4, Nested Selectors and Modular CSS. Finally, you should also notice that although the layouts/_grid.scss partial does not generate a compiled layouts/grid.css file, the .row selector declared in this partial outputs in the compiled stylesheets/main.scss CSS file. In the Using placeholder selectors with the @extend directive recipe of Chapter 4, Nested Selectors and Modular CSS, you will learn how to use the @extend directive, which prevents output in the compiled CSS. Also, mixins, as described in the Leveraging mixins recipe of Chapter 3, Variables, Mixins, and Functions, are not outputted in the final CSS code.

Choosing a strategy to split up or modularize your code is not that easy. In the Applying the OOCSS, SMACSS, and BEM methodologies recipe of Chapter 4, Nested Selectors and Modular CSS, you can read about OOCSS, SMACSS, and BEM; these methodologies help you create modular, reusable, and maintainable CSS code. Applications and web pages are split up into modules and responsibilities, and each of them gets its own partial. Directory structures with partials can reflect your architectural strategy.

Hugo Giraudel, who maintains the Sass Guidelines project, introduced the 7-1 pattern: 7 folders, 1 file. The 7-1 pattern based on SMACSS starts with the following file structure:

Many projects will fit in the preceding structure, but you should realize that architecture is mostly very specific to the project. Depending on your project, you possibly should adapt the 7-1 pattern or even choose a quite different solution.

You will only need your favorite text editor for this recipe.

Use the following steps to set up a new project according the style guidelines:

Style guidelines will tell you how to write your code and guarantee that all the team members can work together on the same code base without spending too much time understanding the other's code. The guidelines should describe the indent in your code and how to nest your selectors. Also, naming conventions are part of the style guidelines. The names of your variables should not only be meaningful and descriptive, but they should also follow the guidelines. Sass variables are explained in Chapter 3, Variables, Mixins, and Functions, of this book.

Which style guidelines you chose does not matter so much, but when you have chosen, you should apply them correctly and consistently. Style guidelines keep your code readable, scalable, reusable, and maintainable.

Alternatively, you can use the scss-lint tool. This tool helps keep your SCSS files clean and readable. You can run it manually from the command line. You can find and read more about the scss-lint tool at http://davidtheclark.com/scss-lint-styleguide/.

The code examples in this book have all been linted with the scss-lint tool. When linting the code, the ColorKeyword linter will be excluded:

scss-lint --exclude-linter ColorKeyword

The ColorKeyword linter checks for usages of the HTML color keywords. The guidelines of the scss-lint tool tell you to use the (short) hexadecimal color notation instead of color keywords. In the examples in this book color names are used because of they are more easy to read.

In some situations, guidelines are ignored when the examples have to show a Sass feature that does not meet the guidelines. So, the PlaceholderInExtend linter does look for usages of the @extend directive without a placeholder, while the Working with partials recipe of this chapter explicitly shows you how the @extend directive can output without using a placeholder.

Also, plugins for the scss-lint tool are available for the VIM, IntelliJ, Sublime Text, Atom, and Emacs editors.

In the Editing and debugging your Sass code in a browser recipe of Chapter 2, Debugging Your Code, you can read how to write and debug your Sass code in a browser. Editing in a browser does not require a text editor at all. When editing your code in a browser, you should not ignore the style guidelines.