Home / Tutorials / Sass / Basic Syntax

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.

Syntax
Comments
Identifiers (names)
Keywords
Scope
Statement termination
Brace convention
Summary: Points to remember

Syntax

Syntax is the specific way we write code. It defines a set of rules for developers when coding, 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

Standard CSS only allows one style of commenting, namely the C++ block comment.

Example:

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

In Sass and SCSS, we are allowed to use single-line comment syntax. A single line 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 always 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 compiled CSS
 * code, even if compressed
 * mode is used
 */

When using Sass, single line comments can make use of the indentation rules. That means if the next line underneath the starting line is indented, it will count as part of the comment.

SCSS doesn’t include this feature because it doesn’t follow indentation rules.

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.

SassDoc uses these comments to build documentation in Markdown. See Suzy's documentation 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 documentation .

For a complete list of VS Code shortcuts, the documentation provides PDF’s for Windows , Mac and Linux .

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

note 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, snake_case or kebab-case to name identifiers.

note Conventions aren’t enforced by the compiler. But, some enterprises may have their own conventions different from the ones below, that you have to follow.

Pascal Case:

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

Camel Case:

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

Snake Case:

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

Kebab Case:

When using kebab case, all words are lowercase. If a name has multiple words, each word is connected with a hyphen.

Example:

// Kebab case
name
first-name

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

Uppercase Snake:

Sass doesn’t explicitly define constants but there is a naming convention we use 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 later on in the course.

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

and	false	from	if
in	not	null	or
through	to	true

You don’t have to memorize the list above, for the moment it’s enough to 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.

First Sass/SCSS Script

Operators