CSS: Lost in methodologies

Writing CSS is easy. Making it scalable and maintainable is not.

How many times:

• did you update the CSS of your application and you broke something else?
• did you wonder where the CSS you have to change is coming from?
• did you update some HTML and it broke your design?
• did you write some CSS and wonder why it wasn’t applied to then discover it was overridden by some other CSS?

This is when you decide there is a better way and come across some CSS methodologies, which seems like a good solution to all those headaches.

You heard of SMACSS, BEM, OOCSS, but at the end of the day, it’s all about what fits your projects.

Also, you may think you’re perfectly fine without them and you may be right. But you might be missing out on big improvements too. You should at least have an idea on what’s out there and why you or you’re not using it.

So what should you use?

First, what is the issue you are trying to solve? Why are you looking into this?

• Prevent your CSS to break each time you touch something?
• Finding CSS you want to change easily?
• Working better as a team?
• Write less to do more?

It’s all about maintainability and reusability.

Now how do you get there?

When eating an elephant take one bite at a time.

• Creighton Abrams

Same apply here. Applying a modular approach to your CSS will save you hours.

Web components are the future of the web and starting now will make your life easier.

Each piece of your app/design helps you build the final results and you should be able to move or replace it without breaking anything else. This is the goal most CSS methodologies aim for.

How to choose what fits your needs?

SMACSS: CSS organisation and architecture

The theory

SMACSS stands for Scalable and Modular Architecture CSS. According to it’s author Jonathan Snook, this is a style guide rather than a rigid spec or framework.

SMACSS is about organising your CSS in 5 rules:

Base

This include selector rules. No classes or id here. This is to reset browser rules and set a base style for elements which are going to be consistent and reused. You are defining here the default style for your elements. This can include html, body, h1, h2, h3, h4, h5, h6, img, a…

Layout

This is where the style used to lay out your pages will sit. It should be separated to your module style for flexibility. You want to be able to use your layout style to build your pages in the most flexible way possible. A module or components should be added to any place in your site independent from the layout.

Using classes instead of id allow you to reuse those layout style anywhere and lower your CSS specificity, making it easier to control.

Modules

A module is a part or a component of your page. Your menu, dialog box, download list or any widget you have on your page. It depends of your design.

A module is independent from your layout so it can live anywhere in you app. You should be able to copy/paste the html and move somewhere else, and it will look and behave the same.

A module should be encapsulated in one file and easily accessible. It will be easy to find and you’ll be in control of what you want to update as it won’t be depending on any other style.

That’s your single source of truth for a feature.

States

A state will be a style which modifies or overrides other rules. A great example is accordion when collapsing or expanding elements. Using a is-collapsed class will make sure your element is collapsed. This is a good place to use !important (and probably the only one) as you want this state to be applied no matter what. Also, it can relate to modified state with javascript.

Good practise is to prefix or add a namespace to those states classes like is- or has-: is-hidden, is-displayed, is-collapsed, has-children, etc

Theme

Idea is to have a file called theme.css where you can define all the theme rules.

// box.scss

.box {
 border: 1px solid;
}

// theme.scss

.box {
 border-color: red;
}

In practise

The first time I read about SMACSS, I found it great but a bit hard to know how to implement it. My approach was mainly through my file architecture.

I tend to have the following directories and file structure:

/ **global**
\_base.scss // Base rules
\_settings.scss
\_states.scss // generic state rules
…

/ **layout**
\_grid.scss
…

/ **modules**
\_card.scss
\_menu.scss
…

As you can see, I have all the layers except the theme one, as I never really needed it.

Perks :

✓ Modular

✓ Flexible

✓ File organisation

✓ States are great reusable classes.

Cons :

• Can be hard to put in practise.
• No class name convention, modules and submodules can be hard to identify

BEM: naming convention

The theory

BEM stands for Block Element Modifier. It’s a naming convention and it works really well with modular CSS.

A block is a module or a component, however you prefer to call it. This is a piece of your design you encapsulate to reuse it anywhere on your site.

**// Block**  
.button {}

**// Element**  
.button\_\_icon {}
.button\_\_text {}

**// Modifier**  
.button — red {}
.button-blue {}

In practise

BEM is great for flexibility. I personally use the SMACSS appellation: module. Therefore, a block is a module. I have a different file per module and BEM allow me to encapsulate those modules perfectly.

When reading the HTML, I know exactly what is part of the module or not and I don’t need to nest my CSS, which means less specificity and then less headaches.

Full example

// Without BEM

.nav ul .item {
 color: black;
 float: left;
}

// With BEM

.nav\_\_item {
 color: black;
 float: left;
}

Perks :

✓ Modular

✓ Flexible

✓ Easy to maintain

✓ Write less CSS

✓ Be in control of your CSS

Cons :

• Long HTML classes
• Verbose

More on BEM

OOCSS: Object Oriented CSS

In theory

OOCSS stands for Object Oriented CSS, and the purpose is to encourage code reusability and ease maintainability.

To do so, OOCSS is based on two principles:

Separate structure from skin

All your elements have some kind of branding, right? Colours, background, borders. Also, they do have a structure which you may sometimes repeat between those elements.

A good example can be a button again.

Before you may have had:

.button {
 display: inline-box;
 width: 200px;
 height: 50px;
 color: white;
 background: black;
}

.box .button {
 color: black;
 background: red;
}

Now with OOCSS:

.button {
 width: 200px;
 height: 50px;
}

.button-default {
 color: white;
 background: black;
}

.button-red {
 color: black;
 background: red;
}

You can see the point. Now you can reuse your CSS for every button and make it less specific.

Separation of containers and content

This is to separate your style from it’s content. You can have a side menu and a box in you main content that applies style to some paragraph.

.sidemenu p {
}

.box p {
}

This ties your HTML and CSS together forever and apply the same style to all p tag in those elements. This may not be what you want.

Also, if you need the same style in your article content for example, you will repeat it again.

Instead, create a new style for this paragraph which you can reuse at any time.

Like BEM, OOCSS avoid specificity through nesting and using ids. It also allows you to apply separation of concerns really easily.

In practise

I didn’t use OOCSS much until recently. I suppose I kind of did by separating colour modules using BEM modifier but I never did it at a large scale.

I found the concept really interesting and start seeing a use in my current company. We have a product which have 3 different skins available on 3 different url. We have the same modules used on most of the 3 websites but with a different branding.

We created objects we reuse on those website and we have modules defining the branding for each websites.

Perks :

✓ High reusability

✓ Ease of maintainability

Cons :

• Can be confusing for new developers. What is an object and what is not? This will force you to document things and introduce new dev to your codebase (which is good to do).

ITCSS: CSS organisation to avoid high specificity

The theory

ITCSS stands for Inverted Triangle CSS. This is a way to organise your CSS according the specificity of your CSS rules.

• Settings : variables, mixins, anything you set to use as setting or functions
• Tools : external includes
• Generic: reset/normalize rules
• Elements : elements base style
• Objects : Object and structure style
• Components : Modules styles
• Trumps : utilities, grid, states

This goes from the less specific rules to the most specific one. This will allow you to take back control of your style.

I am sure we all tried to style an element and adding a rule to find out it doesn’t work because of more specific rule was defined above in your stylesheet.

Controlling your style specificity will save you hours of debugging and hating your colleagues.

In practise

/\* === SETTINGS === \*/

@import “global/site-settings”;
@import “global/mixins”;
@import “global/typography”;

/\* === TOOLS === \*/

@import “libs/material-icons”;

/\* === GENERIC === \*/

@import “global/normalize”;

/\* === ELEMENTS === \*/

@import “global/base”;

/\* == Modules === \*/

// Module example

@import “modules/icon”;
@import “modules/header”;
@import “modules/footer”;
@import “modules/form”;
@import “modules/buttons”;
@import “modules/menu”;
@import “modules/form”;
@import “modules/logo”;

/\* == Trumps === \*/

@import “layout/grid”;
@import “global/states”;
@import “global/utilities”;

Perks :

✓ Lower CSS specificity

✓ Clear organisation

Cons :

• It can be hard to decide what goes into which categories for juniors but this is somethings that can be really clear to more intermediate and senior in my opinion, who should help others.

In a nutshell

We are all aware of it, CSS can turn pretty bad because of it’s own nature.

At the end of the day, it’s about what you need and what makes sense to you. But if you work a large scalable project, what you want is to:

• Control your specificity
• Be modular and create reusable style
• Ease maintenance
• Work better as a team
• Write less to achieve more

All the above can help you do that in their own way. I personally think they work best mixed to fit my needs depending on what makes sense for the project I work on. I keep an open approach rather than “this is what you need to use cause it’s trendy”.

Whats works best for you? What have you been using on your projects? Any other methodologies?