Have you ever worked with CSS that was especially difficult to maintain? Files are given non-descriptive names like "site.css". Each CSS file may contain thousands of lines of CSS that could apply to any feature of the site. Styles on line 120 might be cancelled out or altered by the styles on lines 1200 or 2200.

I have worked with a lot of CSS structured in this way, and the inevitable result was a website design that became less cohesive, less elegant, and more difficult to maintain over time. With any change we make, we risk also changing many things we did not intend to impact. The work becomes more difficult, time-consuming, and expensive.

The price of failing to correct the problem is often developer burnout, which is one of the most expensive problems a web project can have. Fortunately, we have a technique for correcting this problem which has been widely adopted by front-end developers as THE industry standard way to structure CSS. It's called ITCSS.

ITCSS, or "Inverted Triangle CSS", is a method for organizing our entire collection of CSS files into categories and individual CSS files that are easier to maintain and reduce the risks associated with the old method.

Risks of NOT using ITCSS:

• Developer burnout, which could result in talent loss
• Slower onboarding of new developers
• Accessibility errors due to code conflicts, which can result in legal action against your organization
• Adding new features takes exponentially longer, since extensive testing must be done to mitigate code conflicts

Now that you know WHY we use ITCSS, let's look at how it is done.

We begin by creating CSS subdirectories for each category:

1. 📁 Settings
2. 📁 Tools
3. 📁 Generic
4. 📁 Elements
5. 📁 Objects
6. 📁 Components
7. 📁 Utilities

Now, let's break down what CSS goes into each category's subdirectory. Think of these categories as guidelines rather than rules. You may need to adjust how you name and categorize your CSS to better suite your design system.

Inside each directory, we place individual CSS files scoped to logical applications. The files typically lead with an underscore (example: _headings.css) which designates the file as a "partial", or a file intended to be imported into a global CSS file.

1 - Settings

Settings includes things like font imports, color definitions, and preprocessors. Since all my settings are CSS variables, I have named this category "vars" in my example.

If your system has themes, such as color theme options, Settings is a good layer to place these.

📁 Settings examples:

• _vars-primitive.css
• _fonts.css
• _transitions.css
• _theme-light.css
• _theme-dark.css

2 - Tools

Global mixins and functions (if using SCSS). If, like my example, you are not using SCSS or SASS, you may not need this directory.

3 - Generic

Resets, normalizers, box-sizing of all elements, body and HTML margin/padding. Generic styles impact the system at a base level.

📁 Generic examples:

• _base.css
• _resets.css
• _html.css
• _body.css

4 - Elements

HTML element styling. Headings, paragraphs, links, lists. These are not classes, but styles applied to the actual HTML element.

📁 Elements examples:

• _headings.css
• _paragraphs.css
• _lists.css
• _img.css

5 - Objects

Page, section, article, sidebar, main. These are the large containers which govern overall page layout and structure. Your header and footer might belong here, as they appear only once on the page (unlike components, which may appear multiple times on a page).

📁 Objects examples:

• _page.css
• _main.css
• _header.css
• _sidebar.css

6 - Components

Specific parts of the UI which are self-contained, atomic, and modular. Buttons, cards, forms, menus. Each component has a separate CSS file which only impacts that component.

Remember that in the atomic model, a button and a card are separate elements. A button inside of a card is just a "button" - NOT a "card-button".

📁 Components examples:

• _button.css
• _textfield.css
• _card.css
• _menu.css

7 - Utilities

Finally, most systems will sometimes need extra utility classes that can be applied in a specific use case. These should be used sparingly, as they can wreak havoc on a system if we use too many bespoke style exceptions.

📁 Utilities examples:

• _utilities-spacing.css
• _utilities-text.css
• _flexbox.css

There is a lot of documentation available to get you started and help you create an ITCSS architecture that works best for your system.

• ITCSS inventor Harry Roberts explains ITCSS (youtube)
• ITCSS: Scalable and Maintainable CSS Architecture from xfive
• ITCSS: Comprehensive Guide & Starter Framework from Ben Marshall