How to structure your Sass for scalability using ITCSS

When approaching a large project with Sass, it can be tempting to dive right into code and start adding partials into a Sass folder, styling parts of your website or app, and completely forgetting about taking a moment to consider how you might structure your code and implement a strategy for expanding your codebase. When designers or developers lose sight of this important concept during a project, it usually ends up in a messy codebase where a ton of arbitrary partials are being imported into a big style.scss that not only will make it difficult for other developers to follow and understand, but is by no means scalable.

CSS has faults

While Sass has powerful features like functions, loops, and variables, it still doesn’t solve some of the fundamental problems that exist within CSS. There are two main problems that come up when styling CSS at scale that make it difficult to work in a straightforward way.

The first problem exists with the CSS cascade. The issue with cascade is that it makes the entire codebase very highly dependent on source order and exposes a global namespace where selectors can inherit other selectors making it hard to fully encapsulate styles. Because of this design flaw, any new styles we add will always be subject to previous dependencies and, without careful consideration, can quickly become overridden in an undesirable manner.

The second and biggest problem occurs from specificity. When writing highly specific selectors, such as an ID or nested descendant selectors, these styles will problematically bypass the cascade, making it challenging to add additional styles that may be less specific.

These problems need to be addressed at the early stages of a project in order for designers and developers to understand the codebase, to keep new code DRY (Don’t Repeat Yourself), and to allow for scalability.

Harry Roberts’ ITCSS

ITCSS (Inverted Triangle CSS) is an architecture methodology by Harry Roberts for creating scalable, managed CSS. It is primarily a way of thinking about your codebase and a methodology that designers and developers can follow to allow for project clarity and scalability. It’s also not tied to CSS specifically and so therefore can also be used in projects with preprocessors like Sass. The primary idea behind ITCSS is that you should structure your code in an order of specificity. This means your generic styles like global resets and tag selectors (less specific) will go at the top, and you’ll gradually put more explicit styles further down the stylesheet. This creates an “inverted triangle“ shape from the order of specificity. With this methodology, we can begin to structure our Sass in an organized way and follow a strategy when approaching new styles.

Creating layers

The fundamental key to using ITCSS is to divide our styles into layers. These layers will consist of directories that will contain specific aspects of our code with related partials that we can build upon. In a similar fashion to MVC (Model-View-Controller), where you know where to look for certain things, let’s examine each layer and look at what it can be used for.

Settings

These are your global variables and configuration settings. This is where you would put your Sass variables containing all your fonts, typography sizes, colors, paddings, margins, and breakpoints.

Tools

These are your Sass mixins and functions. They could be utility functions or layout or theme mixins.

Generic

These are ground-zero styles. This means things like global resets, box-sizing, or print styles.

Base

This layer contains any un-classed selectors. This means things like h1 tags and p tags. In essence, what does an h1 look like without a class? These partials should be adjustments to base elements.

Objects

In objects, we’re really talking about design patterns like the media object. This is the first layer where you’d begin to use classes. Here you’d want to choose agnostic names that aren’t specific to the type of object. For example, you may have a .slider-list, but not a .product-slider-list. The idea is to keep these cosmetic-free in order to keep them reusable across component instances.

Components

These are more explicit to the type of object. In this case, a .product-slider-list would be in a components/_product-slider.scss partial within this layer.

Trumps

Lastly, the trumps, or “override” layer, should contain high-specificity selectors. These are things like utility classes such as .hide which may use a rule like display none . 

Conclusion

It’s important to remember that when you’re styling a new project, you should consider a structural approach early on and have a strategy like ITCSS that allows for scalability. With a sane environment set up that keeps a clear, contextual separation of styles, you’ll be able to tame and manage the source order, abstract design patterns, and scale your code while leveraging features within Sass.

From 11th to 17th April, you can save 70% on some of our very best web development titles. From ReactJS to Angular 2, we’ve got everything the modern web developer needs. Find them here. 

About the author

Cameron is a freelance web designer, developer, and consultant based in Brooklyn, NY. Whether he’s shipping a new MVP feature for an early-stage startup or harnessing the power of cutting-edge technologies with a digital agency, his specialities in UX, Agile, and front-end Development unlock the possibilities that help his clients thrive. He blogs about design, development, and entrepreneurship and is often tweeting something clever at @cameronjroe.