How do I make my CSS scalable and maintainable? It’s a concern for every front-end developer. ITCSS has an answer.
In 2016, we published an article on ITCSS, where we shared our experience with its implementation into our own development workflow. Back then ITCSS, created by Harry Roberts, was a new CSS methodology.
Resources on ITCSS were rare so our post got to the first position in Google and has stayed there till today. This allows us to share some first-hand data about people’s interest in it.
Over the years, the blog post has accumulated 290k page views. It still gets about 1500 page views a month, but there is a clear declining trend visible.
This is in line with State of CSS 2020 findings, where interest in ITCSS dropped from 40% to 37% in one year.
If we look at Satisfaction vs. Usage diagram from the same resource, we will find ITCSS in the low usage / high satisfaction quadrant.
So why a methodology with high user satisfaction isn’t more popular?
ITCSS remains partially proprietary and there isn’t any open source documentation available. While this prevents ITCSS wider adoption, we respect Harry’s intellectual property. The best way to learn ITCSS is his Skillshare class.
Once you are familiar with the basic ideas, this article helps you gain a wider perspective on ITCSS and fill in some blanks.
ITCSS stands for Inverted Triangle CSS. It helps you organize your project CSS files in such a way that you can better deal with CSS specifics like global namespace, cascade and selectors specificity.
You can use ITCSS with preprocessors or without them and it is compatible with CSS methodologies like BEM, SMACSS or OOCSS.
The main idea of ITCSS is that it separates your CSS codebase into several sections (called layers), which can be represented as sections of an inverted triangle:
Those layers are:
The triangle also shows how styles appear in the resulting CSS: from generic styles to explicit ones, from low-specificity selectors to more specific ones and from far-reaching to localized ones.
Such CSS organization will help you avoid Specificity Wars and will result in a healthy specificity graph.
Over the years of using ITCSS at Xfive, we have collected a few tips on how to work with it.
ITCSS is flexible in terms of your workflow and tools. Are you concerned about the amount of boilerplate involved? This is up to you. ITCSS doesn’t prescribe that you need to have all layers present (only in what order they should be if they are present).
In a minimal setup, you can have just components with default elements styling coming from the browser. Of course, this is not very practical. Almost everyone uses some settings, reset and/or normalize CSS for good reasons.
Use the BEMIT naming convention, especially its Namespaces (.c-user, .o-media, etc.). This will allow you to focus on solving front-end challenges rather than thinking up style names and their location.
In-depth knowledge of BEM helps as well.
Organize ITCSS layers into subfolders and use Sass or another preprocessor to compile newly added files.
@import 'settings/*';
@import 'tools/*';
@import 'generic/*';
@import 'elements/*';
@import 'vendor/*';
@import 'objects/*';
@import 'components/*';
@import 'utilities/*';Store each component to its own file. Do not mix styles from different components in one file like this:
// Don't do this
.c-gallery {}
.c-gallery__image {}
.c-title {}If you use modern UI libraries like React or Vue you can keep all component related files in one folder:
MyComponent/MyComponent.tsx
MyComponent/my-component.scssLimit nesting to 2 levels. Many developers think that using the parent selector (&) is a requirement just because they use Sass. There’s nothing wrong with flat structure with full selectors expanded, either. Often it’s easier to scan and search the code.
.c-teaser {
padding: 2em;
}
.c-teaser--small {
padding: 1em;
}
.c-teaser__title {
font-size: 2em;
}Use the style you prefer, but avoid deep nesting, which results in overqualified selectors. Those are against the spirit of ITCSS.
Objects are the most confusing part of ITCSS. In theory, they make perfect sense, but things can get out of control easily. Check out this example from our own website built a few years ago:
<section class="o-section o-section--more-v-spacing o-section--dark
o-section--above-sidebar c-banner c-banner--dark js-section-above-sidebar">The premise of ITCSS is that it’s easy to track down where particular styles come from and how they affect the styling of elements on the page. This can be difficult to do if the style of a component comes from two or more sources, like an object and a component. But often it’s hard to draw clear boundaries between various CSS properties and whether they belong to an object or a component.
There are a few things you can do to avoid this:
In the words of Max Stoiber, “Margin breaks component encapsulation. A well-built component should not affect anything outside itself.”
A reusable component can appear in different contexts where its distance from other elements may differ. If we try to deal with all the different contexts by adding margins to the component itself, we usually end up with many modifier classes.
One way to solve this in ITCSS is to use wrapper or spacer objects or components. Another, even more flexible solution, would be to create utility classes for margins and spacing, similar to what Tailwind does.
If there is any concern with a component based CSS architecture like ITCSS, it might be style repetition. Components encapsulate styles and allow us to avoid CSS conflicts and overrides, but they can also lead to style repetition.
Don’t worry about style repetition too much and don’t abstract too many styles into objects. It is much easier to update a particular style that is repeated in a few independent components than it is to track down a chain of styles abstracted into multiple objects or components. If you do this too often, utility-first systems might be more suitable for your way of thinking.
At Xfive, we’ve been using ITCSS for the past 5 years. It’s great for those types of projects which don’t come with built-in support for scoping CSS, for example WordPress projects. ITCSS is part of our custom WordPress development framework Chisel.
However, often it’s our go-to approach even on projects where scoping of CSS is more common, for example React projects.
You simply cannot go wrong with ITCSS. It’s the result of the experience and many years of work by Harry Roberts, one of the most respected CSS authors out there. If you don’t mind digging into the resources a bit, you will learn a simple but powerful architecture that will allow you to create scalable and maintainable CSS for your smaller or bigger projects.
