CSS Styleguide

« Back to Index

Table of Contents

  1. Terminology
    1. Rule Declaration
    2. Selectors
    3. Properties
  2. Formatting
    1. Spacing
    2. Nesting
    3. Quotes
    4. Comments
  3. Syntax
    1. Components
    2. Descendants
    3. Modifiers
    4. States
    5. ID Selectors
    6. JavaScript hooks

Terminology

Rule declaration

A “rule declaration” is the name given to a selector (or a group of selectors) with an accompanying group of properties. Here's an example:

.avatar {
  font-size: 18px;
  line-height: 1.2;
}

Selectors

In a rule declaration, “selectors” are the bits that determine which elements in the DOM tree will be styled by the defined properties. Selectors can match HTML elements, as well as an element's class, ID, or any of its attributes. Here are some examples of selectors:

.avatar {
  font-size: 20px;
}
 
#id {
  font-size: 20px;
}

Properties

Finally, properties are what give the selected elements of a rule declaration their style. Properties are key-value pairs, and a rule declaration can contain one or more property declarations. Property declarations look like this:

.avatar {
  background: rgb(255,255,255);
  color: rgb(33,33,33);
}

Formatting

The following are some high level page formatting style rules.

Spacing

CSS rules should be comma separated and leave on a new line:

/* wrong */
.avatar.tweet {
 
}
/* right */
.avatar,
.tweet {
 
}

Properties should use a space after : but not before:

/* wrong */
.avatar {
  font-size : 12px;
}
 
.tweet {
  font-size:12px;
}
/* right */
.avatar {
  font-size: 12px;
}

Rule declarations should have one property per line if they have more than 3:

/* wrong */
.avatar {
  font-size: 12px; letter-spacing: 2px; color: #fff; border: 0;
}
 
.tweet {
  color: #333;
  border: 0;
}
/* right */
.avatar {
  font-size: 12px;
  letter-spacing: 2px;
  color: #fff;
  border: 0;
}
 
.tweet { color: #333; border: 0; }

Declarations should be separated by one blank line:

/* wrong */
.avatar {
  font-size: 12px;
}
.tweet {
  letter-spacing: 2px;
}
/* right */
.avatar {
  font-size: 12px;
}
 
.tweet {
  letter-spacing: 2px;
}

Nesting

Nesting can be used to when an element is dependent of a parent's modifier. This helps to keep all code related to an element on the same block.

.avatar {
  font-size: 12px;
}
    .avatar__photo {
      height: 20px;
    }
    .avatar__title {
      font-size: 1em;
    }

Quotes

Quotes are optional in CSS. You should use single quotes as it is visually clearer that the string is not a selector or a style property.

/* wrong */
.avatar {
  background-image: url(/img/you.jpg);
  font-family: Helvetica Neue Light, Helvetica Neue, HelveticaArial;
}
/* right */
.avatar {
  background-image: url('/img/you.jpg');
  font-family: 'Helvetica Neue Light'Helvetica Neue, HelveticaArial;
}

Comments

Avoid comments as hard as you can. Comments are not easily mantainable and are usually used to supress application design mistakes. Leave comments only to things that are really not straightforward such as browser-specific hacks. Put comments on their own lines to describe content below them.

/* wrong */
.avatar {
  height: 200px; /* this is the height of the container*/
  background-color: rgb(221,33,21); /* brand color */
}
/* right */
.avatar {
  height: 20px;
 
  /* this is a hack to fix click behavior on Safari 6.0 */
  pointer-events: none;
}

Syntax

Syntax: <component-name>[--modifier-name|__descendant-name]

Component driven development offers several benefits when reading and writing HTML and CSS:

OOCSS, or “Object Oriented CSS”, is an approach for writing CSS that encourages you to think about your stylesheets as a collection of “objects”: You can think of components as custom elements that enclose specific semantics, styling, and behaviour.

BEM, or “Block-Element-Modifier”, is a naming convention for classes in HTML and CSS. It was originally developed by Yandex with large codebases and scalability in mind, and can serve as a solid set of guidelines for implementing OOCSS.

Components

Syntax: component-name

The component's name must be written in kebab-case.

.my-component {
  font-size: 20px;
}
<article class="my-component"></article>

Descendants

Syntax: component-name__descendant-name

A component descendant is a class that is attached to a descendant node of a component. It's responsible for applying presentation directly to the descendant on behalf of a particular component. Descendant names must be written in kebab-case.

<article class="tweet">
  <header class="tweet__header">
    <img class="tweet__avatar" src="{$src}" alt="{$alt}">
    …
  </header>
  <div class="tweet__body">
    …
  </div>
</article>

Modifiers

Syntax: component-name--modifier-name

A component modifier is a class that modifies the presentation of the base component in some form. Modifier names must be written in kebab-case and be separated from the component name by two hyphens. The class should be included in the HTML in addition to the base component class.

.btn {
  padding: 20px 10px;
}
 
.btn--primary {
  background: rgb(148,146,231);
}
<button class="btn btn--primary"></button>

States

Syntax: component-name.is-state-of-component

Use is-stateName for state-based modifications of components. The state name must be kebab-case. Never style these classes directly; they should always be used as an adjoining class.

JS can add/remove these classes. This means that the same state names can be used in multiple contexts, but every component must define its own styles for the state (as they are scoped to the component).

.tweet {
  height: 90px;
}
 
.tweet.is-expanded {
  height: 200px;
}
<article class="tweet is-expanded"></article>

ID selectors

While it is possible to select elements by ID in CSS, it should generally be considered an anti-pattern. ID selectors introduce an unnecessarily high level of specificity to your rule declarations, and they are not reusable.

For more on this subject, read CSS Wizardry's article on dealing with specificity.

JavaScript hooks

Avoid binding to the same class in both your CSS and JavaScript. Conflating the two often leads to, at a minimum, time wasted during refactoring when a developer must cross-reference each class they are changing, and at its worst, developers being afraid to make changes for fear of breaking functionality.

We recommend creating JavaScript-specific classes to bind to, prefixed with .js-. To avoid name conflicts, add the component abreviation in the class like: btn, input, a, img

<button class="btn btn-primary js-btn-request-to-book">Request to Book</button>
<input type="text" name="username" class="js-input-username" />
<img src="/img/you.jpg" alt="avatar" class="js-img-avatar" />

⬆ back to top