Atomic Smash homepage splash

CSS Architecture and Methodologies

Words by Adam WardOctober 17, 2016

At Atomic Smash we allocate almost half of our total project time on the planning and requirements stage. We find, that putting more time in to planning, hugely reduces the development and provides much more clarity to the entire team and also client, around timelines and in indentifiying the project’s key challenges. As part of this process the Web Development team get together to explore new technologies and discuss best practices and methodologies to follow throughout the new project.

Large and complex Websites can be prone to messy and inconsistent CSS styling, this is usually due to too many Developer’s working on a project with no set CSS guidelines. These inconsistencies can have a huge impact on development time and make the Website near impossible for future developers to get their head around – I’ve been there!

Organisation can be beautiful...

If you’re anything like me, then badly named files and messy folders on your desktop will hurt your brain and slow you right down. Whereas logical directory structures and descriptive filenames can make development enjoyable and speedy for you and future Developers!

Here at Atomic Smash, our Dev team all use Sass, which is a CSS pre-processor. If you haven’t heard of Sass, then maybe have a quick read and a look at some examples of it in action here – http://sass-lang.com/ . There are a few common ways Developers like to organise their Sass file directories and element names. Each method contains similar techniques and they are all essentially trying to achieve the same goals – to make the code…

 

  1. Logical and easy to read
  2. Modular and flexible
  3. Provide guidelines and a set of rules

 


SMACCS

SMACCS Scalable and Modular Architecture for CSS

The first time I heard about CSS architecture was from a friend who recommended having a look at SMACCS, pronounced “smacks”. The idea behind SMACCS is to order your Sass/CSS files and class/id names in a ‘Modular’ and reusable way. The folder structure is split up in to 5 category types.

  1. Base – CSS Reset/Default Styling/Typography/Links
  2. Layout – Header/Footer/Sidebar/Article/Archive
  3. Module – Card/Block/Modal
  4. State – Hidden/Open/Active/Error
  5. Theme – Theme Specific Colours/Images

 

Having this basic CSS folder structure will force you in to writing more modular CSS. It can certainly take a while to adjust to if you’re used to just writing your CSS, template-by-template, by cutting down on the number of selectors and sticking to more rules will make the project much easier to maintain for future developers and your future self!

SMACCS was created by Jonathan Snook, there’s a book and a ton of videos of Jonathan, explaining the idea behind SMACCS, you can find all the information you need here – https://smacss.com


Atomic Design

Atomic Design Atomic Smash Blog

Atomic Design is a methodology created by Brad Frost, which is inspired by the combination of atomic elements, which make up molecules and organisms. Translated in to CSS, the folder structure would look like this…

  1. Atoms – Labels/Inputs/Buttons
  2. Molecules – Search Form/Navigation/Post Block
  3. Organisms – Header/Footer/Sidebar
  4. Templates – Template blocks/layouts made of combined organisms
  5. Pages – UI variations/Specific design features

 

The idea of Atomic Design is to start with ‘Abstract’ styles in the Atoms directory and move on to more precise or ‘Concrete’ styles in the Templates and Pages directory. This method gives each developer a very clear understanding of where they should be declaring new elements and should help to prevent any repetition.

It’s important to note Atomic Design is much more than just a way of structuring CSS folders! It’s a methodology which centers around design systems and patterns and can be be applied to multiple practices.

Just as with SMACCS, Brad Frost, the creator of Atomic Design has released a book and also has an online version which provides a very detailed explanation of the methodology. You can find it here – http://atomicdesign.bradfrost.com/ .


Naming-your--Styles...

In recent years Style Guides have become more popular and it appears a huge amount of effort goes in to creating them. One of the many great things about style guides, for developers, is clarification around naming elements. Planning how to name styles and elements is just as important as the directory structure. Many Developers have a preferred way of working but it’s important to agree on a set of rules beforehand.

Common naming conventions

BEM – Block Element Modifier

Block: menu
Element: menu__item
Modifier: menu__item–active

.block{__element[–modifier]}

When using the BEM naming method, a ‘Block’ refers to the base component, in the example above this is a menu. A direct child of this block is an element, which would be the menu__item, the double underscore is used when referencing an element. The last part, which is referenced using double hyphens, is a Modifier, which should always relate to the state of a block or element, for example – it could be active, hidden, open, closed etc

BEM – http://getbem.com/introduction/

SMACCS

.l-header
.is-active
.module

SMACCS isn’t as strict when it comes to naming. The main focus is really on the initial directory structure. Generally the idea is to prefix classes and ID’s, which relates to where they sit in the directory. Layout styles should be prefixed with ‘l-‘ or ‘layout-‘, states with ‘is-‘ and modules don’t require prefixes.

SUIT CSS

Utilities
u-[sm-|md-|lg-]

Components
[-][-descendentName][–modifierName]

SUIT CSS uses a mixture of camelCase and hyphens and breaks up classes into Utilities i.e .u-floatLeft, .u-center and Components i.e .headerNav, .fullWidthContainer, components can also use namespaces/prefixes i.e .profile-bodyText, .profile-bodyText–modifier. Just as SMACCS does, SUIT uses ‘is-‘ as a prefix for state change classes.

SUIT CSS – https://github.com/suitcss


I personally find the BEM way of naming my classes very logical and easy for other developers to understand. It’s important to remember this isn’t for everyone and compromises should be made to ensure the entire development team is comfortable, with whichever method you choose.

When deciding on suitable CSS guidelines, I find it very helpful to take a look at how the big players go about it. Below, I’ve include some useful links to some larger companies guidelines –

Airbnb – https://github.com/airbnb/css

Salesforce – https://www.lightningdesignsystem.com/

BBC – http://www.bbc.co.uk/gel

I know it can seem a bit trivial, but having a clear plan and set of rules for everyone to stick to can really help to keep peace within teams and speed up development time. Why not let us know how your team goes about deciding on directory structure and naming conventions, we’d love to hear about it!

Profile picture of Adam Ward

Adam WardDeveloper

Adam is an expert in WordPress development and CRM integrations. His ability to craft WordPress to a users needs makes our websites easier to use.

Go back to top

Keep up to date with Atomic news