Modular CSS: Best practices to improve your coding workflow

Methodology

First thing before you start writing any line of code. Pick a methodology. There are already a couple of approaches out there, all of them developed by very smart folks that faced this problem before us. If you don’t know what a methodology is about: they define a set of rules that give purpose to your CSS classes. In this way, you can categorize and divide (modules) code and reuse it as much as possible.

I will explain a bit one of the different approaches you can take. In this case, it will be SMACCS because it’s the one I use. However, you can also see BEM, Atomic, OOCSS. All of them are good.

SMACCS

Stands for scalable and modular architecture for CSS. In a nutshell, SMACSS defines 5 rules:

Base This you can think of a CSS reset. All rules necessary to standardize your CSS project. No classes or IDs in this section.

body, form { margin: 0; padding: 0; } a { color: #039; }

Layout Set of rules to define your structure. These elements are meant to contain modules inside of it. They set boundaries to produce the layout. E.g: a page with a 2 column layout. Main content / sidebar

.container { width: 960px; margin: auto; } .article { width: 80%; float: left; } .sidebar { width: 20%; float: right; }

Module Elements that build your pages. Things, like carousels, hero images, buttons, etc. They sit inside layout and should be designed to be a standalone component.

.btn { background-color: purple; color: white; padding: 10px; }

State Pretty self-explicatory. This is rules that overwrite the default CSS applied to an element to apply a different state. This could be a navigation that is collapsed, a button that was clicked, a field with incorrect information, etc.

/* Following previous button example */ .is-active { background-color: gray; }

The last rule would be Theme. However, this is something not too many projects share. I will recommend you to check SMACCS documentation (or book) if you are interested to know more the methodology.

I hope you can see the value of having a foundation and why is so important to start with it. Your project will get a structure that everyone in your team knows and can follow. This approach gives you scalability and organization.

Naming convention

After looking at something like SMACSS you are probably thinking: “well if I and my team are going to stick with a methodology we should probably call things the same way”. YES, you are absolutely correct. Naming conventions have been around since the beginning of computing science, they help teams to align things and reduces time on simple tasks like finding a class or file.

CSS is not the exception. You should be able to read anyone’s code and understand if it is a module or a layout (if you are using SMACSS) as well as if you need to create a new class, there are rules to make sure you follow the style guide. This is all really attached to code standards (that’s a topic of its own). But you get the idea… and please, let’s not fight about tabs vs spaces (I am a tabs guys … ? don’t tell anyone).

The previously mentioned methodologies define naming conventions as well and you can use them if you want. I will give you an example of what I normally do.

CSS

// Module .nav { // Modules are always on word no hyphens // ... code } .nav--large { // Submodules are at the same label. always use -- // ... code } .nav__item { // Subcomponents of a module are always follow by __ // ... code } .nav-is-fixed { // State indicates something that's toggled // ... code }

HTML

<ul class=nav nav--large> <li class=nav__item></li> <li class=nav__item></li> <li class=nav__item></li> </ul> <!-- then javascript kicks in and modifies nav --> <ul class=nav nav--large nav-is-fixed> <!-- ... code --> </ul>

When a project gets setup using this kind of approach. The time invested in debugging is reduced considerably because you know where to find the code you are looking for, what does it do and how it’s called. This is a MUST for any mid-large scale project.