When it comes to CSS there are hundreds of coding styles. Over the last few years of working on several projects, I have always found it incredibly difficult to return to a project and remember how all of the CSS is structured. When I began building the UI for Shake I wanted to take the opportunity of having a clean slate to tackle this problem. I began with three main problems I wanted to solve, the CSS code needed to be:

Easy to navigate in order to find the styling for any element as quick as possible. Extremely easy to extend or change designs down the line. Easy to learn for future developers.

Some Ground Rules

Before I began writing any CSS, I wrote out some ground rules.

SASS is awesome, use it.

Using !important is lazy, avoid it.

IDs lead to !important, avoid them.

Use Soft tabs with two space indent.

Avoid deep nesting in SASS.

Styles that only have one style declaration should be written on one line.

UI Components

I had always been interested in the idea of building reusable components. I began searching for various solutions and stumbled across an incredible talk by Jonathan Snook called CSS is a Mess. In this talk, Jonathan speaks about the lack of structure in CSS and introduced me to a great way of building components.

What is a component?

A component refers to a UI element that can be reused in multiple places within an app. The styling of a component should not specify its position on the page just how it and the elements within it appear. UI Components are broken into three style types: Components, Modifiers and States.

1 ) Components

A component is the root level component with its default styling.

.button{

padding: 5px 10px;

borded-radius: 5px;

background: #D5D5D5;

}

2 ) Modifiers

A modifier is a class that can be added to a component to slightly alter the appearance of the component.

.button-action{ background: blue }

.button-warning{ background: red }

3 ) States

A state is a class that can be dynamically added to a component as the application is used to temporarily change the visibility / position of the component.

.button--hidden{ display: none }

Naming Conventions

Naming conventions are important, here’s why:

Let’s say we have a button component.

.button{

// Button styling here

}

This button component also has a large modifier.

.button.large{

// Large button styling

}

After a few weeks of implementing this component inside views you have decided you want to change the style of the large modifier slightly. So you make some changes and its looking good. You then want to check that it looks the same in other views, so you do a project search for “large” only to find 100+ results most not even related to our button component. Ok so maybe instead you narrow it down by searching for “ class=’button large’ ” and it looks like you have got what you want, but you haven’t. Take these elements for example:

<a href="#" class="large button">Click Me</a>

<a href="#" class="button action large">Click Me</a>

Both of these have the large button modifier but will not be returned in our search results. What if you had named the large modifier class ‘button-large’? You would be able to find ever instance where a large button is referenced by simply searching ‘button-large’.

Component Names

All that is important here is that it is clear what the component is.

.modal{}

.button{}

.alert{}

Modifier Names

Modifier names should be defined with the original component name followed by a `-` and then the modifier name.

.modal-large{}

.button-action{}

.alert-warning{}

State Names

State names should be defined with the original component name followed by `—` and the state name.

.modal-—visible{}

.dropdown--hidden{}

Project Layout

When dealing with many CSS files, folder structure becomes important pretty quickly. I separate out my css into the following folders:

├─ base/

├─── reset.scss

├─── mixins.scss

├─── colours.scss

├─ components/

├─── button.scss

├─── modal.scss

├─── etc...

├─ views/

├─── dashboard.scss

├─── another_view.scss

├─── etc...

Base

The base folder contains the things that will be used on almost every view inside the app. This consists mainly of a css reset, branding and any SASS mixins you might need to define. If you are using a lot of SASS mixins you might even consider creating a ‘mixins’ folder inside the ‘base’ folder for further organisation.

Components

The components folder contains all of the css for your UI components. Each component should have its own css file and should not be styled from anywhere outside its CSS file ( unless from a view’s CSS ).

Views

The views folder contains all of the css for your views. Each view does not need to have its own CSS file however if a view has a lot going on it can help to do so. Inside your views, you simply import the base CSS you need and any components in the view.

@import "base/fonts";

@import "base/mixins";

@import "base/colours"; @import "components/modal";

@import "components/button";

etc..

Conclusion

Building a UI using components makes it extremely easy to maintain the front-end of your app. You end up with a library of individual components which all work together to create a view.