SCSS Code Guide

CSS Basics

This document is a very basic reference to our common CSS code styles. Given that we are using SASS, there are some basics about variables and file structures included. We use autoprefixer postCSS Plugin, so there is no need to write them in your code.

Every line of code should appear to be written by a single person, no matter the number of contributors.

by @mdo

Syntax

• Use soft tabs with two spaces—they're the only way to guarantee code renders the same in any environment.
• When grouping selectors, keep individual selectors to a single line.
• Include one space before the opening brace of declaration blocks for legibility.
• Place closing braces of declaration blocks on a new line.
• Include one space after : for each declaration.
• Each declaration should appear on its own line for more accurate error reporting.
• End all declarations with a semi-colon. The last declaration's is optional, but your code is more error prone without it.
• Comma-separated property values should include a space after each comma (e.g., box-shadow).
• Don't include spaces after commas within rgb(), rgba(), hsl(), hsla(), or rect() values. This helps differentiate multiple color values (comma, no space) from multiple property values (comma with space).
• Don't prefix property values or color parameters with a leading zero (e.g., .5 instead of 0.5 and -.5px instead of -0.5px).
• Lowercase all hex values, e.g., #fff. Lowercase letters are much easier to discern when scanning a document as they tend to have more unique shapes.
• Use shorthand hex values where available, e.g., #fff instead of #ffffff.
• Quote attribute values in selectors, e.g., input[type="text"]. They’re only optional in some cases, and it’s a good practice for consistency.
• Avoid specifying units for zero values, e.g., margin: 0; instead of margin: 0px;.

Questions on the terms used here? See the syntax section of the Cascading Style Sheets article on Wikipedia.

/* Bad CSS */
.selector, .selector-secondary, .selector[type=text] {
  padding:15px;
  margin:0px 0px 15px;
  background-color:rgba(0, 0, 0, 0.5);
  box-shadow:0px 1px 2px #CCC,inset 0 1px 0 #FFFFFF
}

/* Good CSS */
.selector,
.selector-secondary,
.selector[type="text"] {
  padding: 15px;
  margin-bottom: 15px;
  background-color: rgba(0,0,0,.5);
  box-shadow: 0 1px 2px #ccc, inset 0 1px 0 #fff;
}

Class names

• Keep classes lowercase and use dashes (not underscores or camelCase). Dashes serve as natural breaks in related class (e.g., .btn and .btn-danger).
• Avoid excessive and arbitrary shorthand notation. .btn is useful for button, but .s doesn't mean anything.
• Keep classes as short and succinct as possible.
• Use meaningful names; use structural or purposeful names over presentational.
• Prefix classes based on the closest parent or base class.

It's also useful to apply many of these same rules when creating SCSS variable names.

/* Bad example */
.t { ... }
.red { ... }
.header { ... }

/* Good example */
.tweet { ... }
.important { ... }
.tweet-header { ... }

Selectors

• Use classes over generic element tag for optimum rendering performance.
• Avoid using several attribute selectors (e.g., [class^="..."]) on commonly occuring components. Browser performance is known to be impacted by these.
• Keep selectors short and strive to limit the number of elements in each selector to three.
• Scope classes to the closest parent only when necessary (e.g., when not using prefixed classes).

Additional reading:

• Scope CSS classes with prefixes
• Stop the cascade

/* Bad example */
span { ... }
.page-container #stream .stream-item .tweet .tweet-header .username { ... }
.avatar { ... }

/* Good example */
.avatar { ... }
.tweet-header .username { ... }
.tweet .avatar { ... }

Single declarations

In instances where a rule set includes only one declaration, consider removing line breaks for readability and faster editing. Any rule set with multiple declarations should be split to separate lines.

The key factor here is error detection—e.g., a CSS validator stating you have a syntax error on Line 183. With a single declaration, there's no missing it. With multiple declarations, separate lines is a must for your sanity.

// Bad: Single declarations on one line
.span1 { width: 60px; }

.span2 { width: 140px; }

.span3 { width: 220px; }

// Good: Multiple declarations, one per line
.sprite {
  display: inline-block;
  width: 16px;
  height: 15px;
  background-image: url('../img/sprite.png');
}

.icon {
  background-position: 0 0;
}

.icon-home {
  background-position: 0 -20px;
}

.icon-account {
  background-position: 0 -40px;
}

Shorthand notation

Strive to limit use of shorthand declarations to instances where you must explicitly set all the available values. Common overused shorthand properties include:

• padding
• margin
• font
• background
• border
• border-radius

Often times we don't need to set all the values a shorthand property represents. For example, HTML headings only set top and bottom margin, so when necessary, only override those two values. Excessive use of shorthand properties often leads to sloppier code with unnecessary overrides and unintended side effects.

// Bad example
.element {
  padding: 10px 10px 10px 10px;
  margin: 0 0 10px;
  background: $red;
  background: url('image.jpg');
  border-radius: 3px 3px 0 0;
}

// Good example
.element {
  padding: 10px;
  margin-bottom: 10px;
  background-color: $red;
  background-image: url('image.jpg');
  border-top-right-radius: 3px;
  border-top-left-radius: 3px;
}

Comments

Code is written and maintained by people. Ensure your code is descriptive, well commented, and approachable by others. Great code comments convey context or purpose. Do not simply reiterate a component or class name.

Be sure to write in complete sentences for larger comments and succinct phrases for general notes.

// Bad example
// Modal header
.modal-header {
  ...
}

// Good example
// Wrapping element for .modal-title and .modal-close
.modal-header {
  ...
}

Variables

Ensure you extract component variables to the top of the component file. It helps other developers to get an overview of the available settings.

// Declare Component specific Variables on top of the file

$example-var: 200px !default;
$mega-class-color: $theme-main-color;

.mega-class {
  height: $example-var;
  background-color: $mega-class-color;
}

Media query placement

Always thinking from small screens to larger, place media queries at the end of the previous properties. Don't bundle them all in a separate stylesheet or at the end of the document. Doing so only makes it easier for folks to miss them in the future.

Name Breakpoints as general as possible.

// Defining values
$screen-sm-min: 768px;
$screen-xs-max: ($screen-sm-min - 1);
$screen-md-min: 992px;
$screen-sm-max: ($screen-md-min - 1);
$screen-lg-min: 1200px;
$screen-md-max: ($screen-lg-min - 1);

// Usage
.element {
  width: 100px;

  @media (max-width: $screen-xs-max) {
    width: 300px;
  }

  @media (min-width: $screen-sm-min) {
    width: 800px;
  }
}

Declaration order

Related property declarations should be grouped together following the order:

1. Positioning
2. Box model
3. Typographic
4. Visual

Positioning comes first because it can remove an element from the normal flow of the document and override box model related styles. The box model comes next as it dictates a component's dimensions and placement.

Everything else takes place inside the component or without impacting the previous two sections, and thus they come last.

.declaration-order {
  // Extensions and mixins are declared at top of the class
  @extend %clearfix;

  @include hover-shadow();

  // Positioning
  position: absolute;
  top: 0;
  right: 0;
  bottom: 0;
  left: 0;
  z-index: 100;

  // Box-model
  display: block;
  float: right;
  width: 100px;
  height: 100px;

  // Typography
  font: normal 13px 'Helvetica Neue', sans-serif;
  line-height: 1.5;
  color: $blue;
  text-align: center;

  // Visual
  background-color: $green;
  border: 1px solid $rebeccapurple;
  border-radius: 3px;

  // Misc
  opacity: 1;
}

Nesting

Avoid unnecessary nesting. Just because you can nest, doesn't mean you always should. Consider nesting only if you must scope styles to a parent and if there are multiple elements to be nested. Ensure that outcoming css is still readable.

// Without nesting
.table > thead > tr {
  color: $blue;
}

// With nesting
.table {

  thead {

    tr {

      color: $blue;

    }
  }
}

Operators

For improved readability, wrap all math operations in parentheses with a single space between values, variables, and operators.

// Bad example
.element {
  margin: 10px 0 @variable*2 10px;
}

// Good example
.element {
  margin: 10px 0 (@variable * 2) 10px;
}

Statements

Read more about statements in SCSS.

/* Give statements a good default */

$red: #f00 !default;
$blue: #00f !default;
$theme: false !default;

.class {

  @if ($theme == true) {
    background-color: $red;
  } @else {
    background-color: $blue;
  }
}

Mixins

Use mixins if you use at least on argument, so it can be reused and modified. If it is more component specific, give it some good defaults. Otherwise use a simple placehoder. You can use placholders together with mixins to make the code more structured.

Also consider using SCSS functions which only returning one value.

// Good Example

@mixin theme-background($bg: #f55) {
    background-color: $bg;
}


// Bad Example

@mixin button {
    padding: 10px;
    color: #fff;
    background-color: red;
    font-size: 14px;
    width: 150px;
    margin: 5px 0;
    text-align: center;
    display: block;
}

.wrapper {
  @include theme-background(#0f9);
}


// Placeholder

%bg-image {
    width: 100%;
    background-position: center center;
    background-size: cover;
    background-repeat: no-repeat;
}

.image-one {
    @extend %bg-image;
    background-image:url(/img/image-one.jpg");
}

Organization

• Organize sections of code by component.
• Develop a consistent commenting hierarchy.
• Use consistent white space to your advantage when separating sections of code for scanning larger documents.
• When implementing new styles, try to describe them in a reusable way.

//Component section heading

.element {
  // ...
}

// Contextual sub-component or modifer
.element-heading {
  // ...
}

SCSS Lint

To ensure the rules of this Guideline make use of a SCSS/SASS Linter with the settings found in: .sass-lint.yml

SASS Docs

It's highly recommended to document your SCSS Code. Documentation specific Comments will be parsed and end up in a HTML file.

// ----------------------------------------------------------------------

  // Item size

// ----------------------------------------------------------------------

////
/// @author Damien Hirn
/// @group bsc
///
/// @access public
///
/// @param {Length} $width - Element’s `width`
/// @param {Length} $height ($width) - Element’s `height`
///
////

/// Set Elements size
///
/// @example scss - Basic Usage Sass
///    .icon-sm {
///        @include item-size(10px);
///    }
///
/// @example scss - Basic Usage CSS Output
///    .icon-sm {
///        height: 10px;
///        width: 10px;
///    }

@mixin item-size($height, $width: $height) {
  height: $height;
  width: $width;
}

Editor preferences

Set your editor to the following settings to avoid common code inconsistencies and dirty diffs:

• Use soft-tabs set to two spaces.
• Trim trailing white space on save.
• Set encoding to UTF-8.
• Add new line at end of files.

Consider documenting and applying these preferences to your project's .editorconfig file. For an example, see the one in Bootstrap. Learn more about EditorConfig.