SMACSS (Scalable and Modular Architecture for CSS)

Last week we talked about OOCSS (Object Oriented CSS), going over the good points and the bad points, and tried to determine whether it was the right fit for our different use cases.

To recap, these are our three example users:

Single user/hobbyist/lone-ranger (Alex)
Small agency/friends collaborating/3-4 developers (Tuco)
Large agency/corporation/5+ developers (Mary)

This week we’ll be talking about…

##SMACSS (Scalable and Modular Architecture for CSS)

From the name, this sounds like OOCSS, being modular and scalable - however SMACSS is a set of rules that lets you ensure your CSS is scalable and modular.

In short, the way this works is by organising your CSS into 5 specific categories.

In more detail, the 5 organisation categories of SMACSS are:

####Base

This is where your default styling for primary/common elements go, for example body, a, p tags. This is also where any of your CSS resets go.

An example of what you might see in ‘base’ css file:

body {}
h1, h2, h3, h4 {}
a {}
p {}

Base CSS code are often split out into multiple files in larger projects as there can be quite a lot of base styling. As an example, you could separate your base out into a file structure such as this:

/ base
  / buttons.css
  / forms.css
  / headings.css
  / resets.css

####Layout

Here you should put styling that is specific to the structure of your project, and individual sections and/or pages. This CSS is used to build your groundwork, and bind other modules together, rather than specifically defining everything here.

An example of what you might see in a ‘layout’ CSS file:

header {}
footer {}
.container {}

article {}
section {}

If you’re using SCSS/SASS/LESS, you could organise your layouts by defining the base element of a layout, followed by including modules as necessary. For example:

header
  @include navigation
  @include logo

footer
  @include navigation
  @include copyright

article
  @include headings
  @include content

Each of these modules will define what they are, and can be included as necessary into the different layouts.

Layouts should also include any page specific styling, for example you could build your homepage layout as follows:

body.home
  @include breadcrumbs

  article
    @include hero
    @include quotes
    @include clients
    @include contact-form

####Modules

Like we’ve already covered in OOCSS, these are reusable chunks of CSS. These normally contain blocks of CSS that define a reusable element. In plain ol’css you can define these and just let your html use them as is. When using a CSS preprocessor, you can include these modules into your layout CSS.

For an example of what you might see in one of these modules, see the OOCSS (Object Oriented CSS) post.

####State

These define variations of elements depending on certain conditions, for example hover, focus, active, hidden etc. It’s good to define these separately, but they will be part of the modules that you create. How you organise these us somewhat up to you, but i’ll give you some examples of how you could accomplish this:

You could add them as part of your modules, for example:

.navigation {}
.navigation li {}

.navigation li.active {}
.navigation li:hover {}

Or in a preprocessor:

@mixin navigation
  li
    &.active
    &:hover

Or you could have your states defined separately, and include them where necessary:

@mixin navigation-states
  li.active
  li:hover

@mixin navigation
  @include navigation-states

   li

####Theme

This is similar to state, but it’s more about defining how the modules/layouts will look rather than how they behave. Most projects won’t really need to separate their styles into themes, but you may find it a good practise to follow anyway. It will make it easier to change how things look without changing how they work at a later date. Primary, themes are used to let you build multiple different looking versions, while sharing base styling rules.

If you did decide you wanted to use themes, you could use them in a couple of different ways, for example:

You would have your structure styling as follows:

/ base
/ layout
/ modules

And any themes you would add in a folder, with the same structure, for example:

/ base
/ layout
/ modules
/ themes
  / buyapowa
    / base
    / layout
    / modules

An example of how you might do your styling with theming is as follows:

You have a navigation module in modules/navigation:

.navigation {
  border: 1px solid
}

And in your themes navigation module in themes/modules/navigation, you could have:

.navigation {
  border-color: blue
}

Now we’ve gone through what SMACSS is, I’ll run over the good and bad points:

####Good points

A simple set of rules for laying out your CSS means not only will you always know where things should be, anybody else who knows SMACSS will too
Takes separation of concerns to another level
The rules are loose, and can be applied as required by your organisation

####Bad points

As they are only a loose set of rules, naming conventions may become confused between individuals
Separating things out so much can get a little confusing when looking for a particular piece of code

###Who should use SMACSS?

Alex - Sometimes
It’s always nice to organise your code so that everything is separated out into their own concerns, but it may not be so necessary for Alex to conform to a SMACSS layout rigidly. Categorising CSS into base, layouts and modules is probably enough for 99% of the projects Alex does.

Tuco - Mostly
When you’re working with another person, you should definitely have a form of organising your CSS. SMACSS is great for Tuco and the team as it’s a loose set of structuring rules that they can apply however they like. However - when creating small prototypes and short lived projects, sticking to the team’s SMACSS layout shouldn’t be a requirement.

Mary - Yes
SMACSS was formed as result of rebuilding Yahoo! mail. If that isn’t proof enough that SMACSS is for large organisations, then I don’t know what is. then Mary, I don’t know what is. Like Tuco - in a team of more than 1 person, organising CSS clearly should be of paramount importance. And having a single set of rules that the whole team can follow will help everyone.