Basic Sass/SCSS Syntax & Conventions Tutorial

In this tutorial we learn the basics of Sass and SCSS and the key differences in their syntax when defining scope and terminating statements.

We cover how to comment our code and enhance its readability, naming rules and conventions, brace conventions and keywords with special meaning.

Here's a table of contents of what you'll learn in this lesson:
(click on a link to skip to its section)

Let's jump right in.

Syntax

Syntax is the specific way we write code. It defines a set of rules for developers, and every programming or scripting language defines its own syntax.

Sass and SCSS have some small variations in their syntax that are covered in this lesson.

Comments

CSS has only one style of comment, the C++ block comment.

Example:
/* I am the only type of
 * comment that is valid
 * in standard CSS
 */

Sass provides us with the added option to use single-line comment syntax, where the comment starts with two slashes and ends with a newline.

Example:
// I am a single line comment and only span a single line

Single line comments are not converted to CSS block comments when the script is compiled. They are excluded from the compilation.

Block comments in Sass are included in the compiled CSS code, unless we compile in compressed mode.

Additionally, if we add an exclamation mark to the start of a block comment, it will be included in the compiled CSS code even if we use compressed mode.

Example:
// I am not included in the
// final compiled CSS code

/* I am included in the final
 * compiled CSS code unless
 * compressed mode is used
 */

/*! I am always included in
 * the final compiiled CSS
 * code, even if compressed
 * mode is used
 */

Indented Sass comments can make use of the indentation rules.

This means that we can start a comment and if a line underneath it is indented, it will count as part of the comment.

Example:
// I am an indented Sass
   comment and will work
   until the compiler
   finds an empty line
   between me and the next
   piece of code

body
  background: orange

Comment blocks also don’t need to be closed unless they live between code.

Example:
/* I am an indented Sass
   block comment and don't
   need to be closed unless
   I live between code

/*! Me too

body
  background: /* If I'm inline, I need to be closed */ orange

Another type of comment Sass allows is the documentation comment.

SassDocOpens up in a new page uses these comments to build documentation in Markdown. See Suzy's documentationOpens up in a new page as an example.

Documentation comments are single line silent comments but use three slashes instead of two.

Example:
/// I am a documentation
/// comment. Use SassDoc
/// to turn me into
/// actual documentation

If you’re using VS Code as your IDE, you can use the following shortcuts to quickly comment out code.

Windows:

Single-line comment: Ctrl + / Block comment: Ctrl + Alt + A

Mac:

Single-line comment: Cmd + / Block comment: Shift + Option + A

Linux:

Single-line comment: Ctrl + / Block comment: Ctrl + Shift + A

For more information on customizing keybindings, see the official VS Code documentationOpens up in a new page .

For a complete list of VS Code shortcuts, the documentation provides PDF’s for WindowsOpens up in a new page , MacOpens up in a new page and LinuxOpens up in a new page .

Identifiers (names)

An identifier is the name we use to identify things like variables , mixins etc.

There are a few rules and conventions when it comes to our identifiers, let’s go through some of them now.

1. A name cannot start with a number, but may contain a number inside of it.

Example:
// Not allowed
21_Jump_Street

// Allowed
mambo_number_5

This only applies to mixin and function identifiers. Variable names always start with a dollar symbol.

2. A name may start with uppercase or lowercase alphabetical letters (A - Z or a - z), underscores ( _ ) or dollar symbol ( $ ).

Example:
// Allowed
Name
name

// Allowed for variables
$name

// Allowed but not
// conventional
_name

3. A name may not contain special characters such as @, &, % etc.

Names that start with an @ symbol is called an at-rule and has special meaning to both Sass and CSS.

The & symbol is called the Parent Selector and is used for nesting in Sass.

Example:
// Not allowed
^_^
usern@name
#lostsock#thestruggleisreal

4. Most names are case sensitive, which means that a name with lowercase letters is not the same as a name with uppercase letters.

Example:
// Not the same
$learning
$LearNing
$LEARNING

5. Hyphens and underscores are treated as the same in Sass.

Example:
// Treated as the same
$multiple-word-name
$multiple_word_name

6. A name should not contain a Sass specific keyword. Keywords are words that are reserved for special uses.

Example:
// Allowed but bad-practice
$false
$null
$through

Let’s take a look at the popular conventions to name identifiers in Sass. Typically, developers will use PascalCase, camelCase or snake_case to name identifiers.

Conventions aren’t enforced by the compiler. Some enterprises may have their own conventions different from those below.

When using pascal case, the first letter of a word is uppercase. If the name has multiple words, each new word is directly connected to the previous word but the first letter is also uppercase.

Example:
// Pascal case
Name
FirstName

When using camel case, the first word of a name is lowercase. If a name has multiple words, each new word is directly connected to the previous word but the first letter is uppercase.

Example:
// Camel case
name
firstName

When using snake case, all words are lowercase. If a name has multiple words, each word is connected with an underscore.

Example:
// Snake case
name
first_name

There is also the hyphen variation of snake case where multiple words are connected with hyphens instead of underscores.

Example:
// Snake case (hyphen)
name
first-name

As mentioned before, hyphens and underscores in identifiers are treated as the same.

Sass doesn’t explicitly define constants but there is a naming convention when we want to indicate that a value shouldn’t be changed.

This convention is the uppercase snake, where all words are uppercase and if a name has multiple words, each word is connected with an underscore.

Example:
// Constants
FIRST_NAME

It doesn’t really matter which convention you use, as long as you stay consistent.

If you name a variable in snake_case, don’t name other variables in camel or pascal case later in the code.

Keywords

Keywords are reserved words that have a special meaning to Sass compiler.

For example, a @for loop contains the keywords, from and through. In the context of the loop, they have meaning and purpose.

Example:
$font-size: (24px, 22px, 20px, 18px);

@for $i from 1 through 4 {

  h#{$i} {
    font-size: nth($font-size, $i);

  }
}

Special keywords shouldn’t be used as identifiers in Sass.

If you don’t understand the code above, don’t worry. We cover loops in depth in the Iteration Control lesson .

Following is a list of keywords for Sass (excluding any CSS specific keywords).

andfalsefromif
innotnullor
throughtotrue 

You don’t have to memorize the list above, for the moment it’s enough to simply know they exist. We cover them in more detail throughout the course.

Scope

Like standard CSS, SCSS defines scope with open and close curly braces.

Example: CSS/SCSS
body {
  // Everything inside the
  // open and close curly
  // braces belongs to body
  // It's in the body local
  // scope
}

Indented Sass on the other hand, defines scope with indentation. A single level of indentation defines local scope.

Example: Sass
html
  // I am scoped to html
  color: white
body
  // I am scoped to body
  background: black

When nesting, more than one level of indentation is required.

Example: Sass
a
  // Single indentation
  color: white
  text-decoration: none

  // Nested hover
  &:hover
    // double indentation
    color: red
    text-decoration: underline

If we don’t indent properties to their appropriate level, the compiler will raise an error and refuse to compile the code.

Example: Sass
body
background: black

The example above will raise the following error message in the terminal.

Output:
This selector doesn't have any properties and won't be rendered.

This is one of the reasons SCSS is more popular. The indentation can become confusing easily, especially when a developer is several levels deep.

Example:
a {
  color: white;
  text-decoration: none;

  // Nested hover
  &:hover {
    color: red;
    text-decoration: underline;
  }
}

In the SCSS example above, the scope is much clearer to see at a glance.

We cover nesting in more detail in the nesting lesson.

Statement termination

Also like standard CSS, SCSS terminates statements with the semicolon operator.

This also allows us to define properties on the same line.

Example: SCSS
body {
  background: black; color: white;
}

With indented Sass we terminate statements with a newline.

Example: Sass
body
  background: black
  color: white

Each statement must be on its own line, or the compiler will raise an error.

Example: Sass
body
  background: black color: white
Output:
Error: expected newline.

Brace convention

In SCSS we’re allowed to place our open curly braces on the same line as the header, or on its own line.

Example:
// CSS convention
@mixin list-reset {
  margin: 0;
  padding: 0;
  list-style: none;
}

// C/C++ style convention
@mixin list-reset
{
  margin: 0;
  padding: 0;
  list-style: none;
}

Many developers favor the compactness of writing the brace with the header. Others prefer, as is sometimes necessary, a visual break after the header.

Example:
// Compact
@mixin list-reset {
  margin: 0;
  padding: 0;
  list-style: none;
}

// Visual break
@mixin list-reset {

  margin: 0;
  padding: 0;
  list-style: none;
}

However, many other developers feel that when a visual break is used, it shows clearer when the brace is on the line of the break.

Example:
// Visual break
@mixin list-reset {

  margin: 0;
  padding: 0;
  list-style: none;
}

// Cleaner visual break
@mixin list-reset
{
  margin: 0;
  padding: 0;
  list-style: none;
}

Typical SCSS convention is to place opening curly braces on the same line as the header so that’s what we will use in this tutorial course.

Your employer or team may require you to follow their own convention. Otherwise, choose the one you prefer, but stay consistent.

Summary: Points to remember

  • Sass and SCSS supports both styles of C++ comments, the block comment and the single-line comment.
    • A block comment starts with /* and ends with */ just like in standard CSS.
    • A single-line comment starts with // and ends with a newline.
  • Keywords are reserved words in Sass that have a special meaning and shouldn’t be used as identifiers.
  • SCSS defines scope with open and close curly braces, like CSS.
  • Sass defines scope with indentation instead of curly braces.
  • SCSS terminates statements with a semicolon and allows multiple properties on a single line.
  • Sass terminates statements with a newline and doesn’t allow properties on a single line.