CSS

Philosophy

At Built By Cactus we want our websites to shine and for users to have the best possible experience they can. This means that whilst we try and stay up to date with new tools and techniques we should also think about how this will affect our users.

For example, there’s no point in us building an all-singing, all-dancing website if only 20% of users can actually view it properly.

We build mobile first, using performant CSS that’s well-structured. This makes maintaining a site 100x easier.

Overview

Standardised syntax and formatting are key to a maintainable project. By keeping our code style consistent, we make it much easier for anyone that has to maintain a project to do so!

We prefer to use SCSS over Sass so unless asked by the client, please stick to this.

BEM

We use BEM naming for our CSS/SCSS wherever possible. This makes our code more maintainable and out CSS easier to read.

If you’re new to BEM, please see here for an introduction on naming your classes and elements.

SCSS Structure

When structuring your SCSS, please make use of a logical directory structure. Something like the below is preferred:

styles                      # Main style directory
├── common                  # Files that are used throughout the project
│   ├── _global.scss        # Global styles such as setting of base font size
│   ├── _variables.scss     # Any variables for the project
├── blocks                  # Styles for each block type will go in here
├── components              # Styles for any standadised components buttons etc.
├── layouts                 # Layout styles that can be re-used
├── pages                   # Page level overrides
├── main.scss               # Main SCSS file

CSS Syntax

CSS syntax is not strict and there are hundreds of ways to structure it, but for the sake of legibility and fast debugging, we follow basic code styles:

• Write one selector per line
• Write one declaration per line
• Closing braces should be on a new line

// No
.div-1, .div-2, .div-3 {
  color: red;
  background-color: yellow;
  height: 50em;
}

// Yes
.div-1,
.div-2,
.div-3 {
  color: red;
  background-color: yellow;
  height: 50em;
}

• Include one space before the opening brace
• Include one space before the value
• Include one space after each comma-separated values

// No
.div-1, .div-2 {
  color: red;
  height: 50em;
  box-shadow: 0 1px 5px #000, 1px 2px 5px #ccc;
}

// Yes
.div-1,
.div-2 {
  color: red;
  height: 50em;
  box-shadow: 0 1px 5px #000, 1px 2px 5px #ccc;
}

• Try to use lowercase for all values, except for font names
• Zero values don’t need units
• End all declarations with a semi-colon, even the last one, to avoid errors
• Use double quotes instead of single quotes
• If you don’t need to set all the values, don’t use shorthand notation.

// No
.div-1 {
  color: #FFF;
  margin: 0em;
  font-family: 'Times New Roman', serif;
  padding: 0 0 0 10px;
}

// Yes
.div-1 {
  color: #fff;
  margin: 0;
  font-family: "Times New Roman", serif;
  padding-left: 10px;
}

Nesting

Nesting has changed the face of SCSS and Sass but can also be a massive hindrance. Not only does it get abused very often, it can become hard to read and confusing to look at. Therefore, use nesting sparingly. If using BEM properly, you should only need it in the following cases:

• pseudo-classes
• pseudo-elements
• component states
• media queries