Styleguide

Overview

Here at Hired we have a homegrown CSS framework intended to empower creativity with low friction tooling. If you're new, these docs are designed to be read straight through.

How to Use This Guide

  1. Grok the code patterns outlined in Overview
  2. Grok the design patterns and their tools in Design
  3. Reference re-usable concepts in Components

All PRs/Issues on github are welcome. Check out our contribution guide and open a PR/issue about anything!

Object Oriented CSS

The purpose of 'Object Oriented CSS' is to create reusable components that ensure consistency among elements, wherever they may be used. Using the BEM naming methodology, Fortitude encourages you to break apart structural properties of a component from the stylistic properties.

Let's take a look at an example. The .button class (in our rendition of Fortitude) contains the following: .button { font-weight: $medium; letter-spacing: .15rem; user-select: none; transition: all .1s ease-in-out; text-transform: uppercase; }

You'll notice there are no visual rules (like color, border, etc.) defined on this base .button class. Instead, it only contains the core structural scaffold for what all buttons will share.

.button--primary, however, is a different story. Using BEM we know that .button--primary is a modifier of .button, so it will contain the visual aspects of a particular kind of button. .button--primary { background-color: $brand-green; border-color: $brand-green; color: $brand-white-light; }

To render this type of button, we would add both the .button and .button--primary to our element. This will give it both the structure of .button, as well as the visual styling of .button--primary.

%button.button.button--primary My button

  By George, we have a button!

But Why?

You may be asking yourself, why are we adding all of these classes just to get a simple button?

We separate the visual aspects of a component in these modifying classes (like .button--primary) so that we can infinitely extend our primary .button without continuing to repeat all the core building blocks over and over again. In addition, if later on down the road we change a structural aspect of how .button is layed out, we only need to change the one .button class.

With so many classes, we can rapidly prototype without ever writing CSS.

There is a learning curve to memorizing all of the helpers and components, but once fluent you can move very fast.

Over time we sculpt the scattered markup into more robust, reusable components.

Next let's learn how to create a safe CSS sandbox that won't leak elsewhere in the app.

Each page has its own sandbox with at least a few handy styles for DRYing up markup are declared.