There are UI and UX enthusiasts who honor the power of it to paint the web while there are developers who take a huge sigh when new changes to the existing codebase have to be introduced. I am talking about CSS and it’s controversial perspectives among developers. However, no matter how your attitude towards CSS is, as a fronted web dev it’s a major part of your work to provide an appealing UI to your customers. As a result it’s nearly inevitable to skip touching CSS code. I can imagine a few readers at this point shaking their heads and thinking things like “Why does he write a blog post about CSS. It’s just a few selectors with style properties. What should be complex here?”. When I did my first steps in web development and especially in CSS I thought quite the same until I had to deal with my first larger CSS codebase along with the fact of working on it in a team. This experience opened my eyes and made me thinking of whether there are better ways to handle and scale CSS. Luckily I found a promising answer to my question which I want to discuss in this blog post.

What are the main problems?

Before outlining potential solutions it has to made clear what the actual problems with CSS are. From my experience and learnings about this topic so far, I would say that despite it’s apparent simplicity CSS is hard to get right. What I got out of this in the last days and weeks is that both CSS as language and the developers do certain things wrong. It is definitely true that stuff like the dependence on order of source code, the cascading nature or the specificity concept of CSS make maintaining and working with it harder. However, from my point of view the things developers do wrong are more important since I think there have to be ways to deal with these peculiarities of the language. Therefore, following list should outline the issues CSS projects usually cause.

• Lack of of structureI was not aware of any structure paradigm in CSS until recently. When working in a company you usually work within different projects, different teams and the problem with missing paradigms is that people don’t bother where to put things. In software engineering for instance there are well-known patterns like MVC which provide a structure and guidance for developers. You will always know where you find certain things like models or controller classes. In CSS this lack of structure from my experience was probably often the starting point of messing things up. Putting new styles at the bottom of a CSS file or duplicating CSS code are just two examples lack of structure will cause.

• Different ways of workingIf more people are working on CSS code within the same project and you have no guidance, conventions or structural requirements this contributes further to a gigantic CSS mess. People work differently, have a different understanding of CSS and will introduce completely unrelated styles over time. Unfortunately especially CSS is very prone for this, since it is not expressive and offers many ways to do a particular thing. My experience has shown that people, and I am no exception, started to realize that the CSS code gets more messy from day to day and I am not talking about huge projects lasting over years. This already starts in rather small projects.

• Knowledge of CSS in general or in a particular projectThis comes especially from experience in a smaller team which works multidisciplinary and where writing CSS takes on only little time of the overall work. People tend to have different views and backgrounds on CSS which can make writing scalable CSS in a team more difficult.

• Missing documentationAs in all software development branches, writing documentation is not a fun part for developers. It is often neglected, sometimes it’s definitely no failure to leave out some code comments when the code is expressive enough to explain what’s going on. Exactly this expressiveness is missing in CSS at all and as a result documenting things would be of advantage.

The idea of ITCSS

I hope you agree with me that these problems give some reason to be tackled and it’s time to write better CSS code. I used an open space conference in October in Linz to discuss how other people deal with these problems and tried to find ways to improve CSS development. I was introduced ITCSS (Inverted Triangle CSS) and immediately liked this idea of organizing CSS. ITCSS is not a library or framework you can apply but rather a mindset of how to structure CSS. It’s a layered architecture providing a guideline on how your CSS should be structured. The following figure illustrates the architecture of ITCSS.

Figure from: https://www.xfive.co/blog/itcss-scalable-maintainable-css-architecture/

As shown in the figure, ITCSS proposes seven different layers ordered in an inverted triangle. The idea is to start with the most generic styles in the top layers and get more specific in each layer moving downwards. Using this approach turns out to be very powerful with CSS due to the two main properties cascading and specificity. ITCSS helps to overcome the problem that the browser has to jump forwards- and backwards in an CSS file to apply styles on the one hand and the issues of adding extra selectors or !important just to make things more specific and overwrite other styles on the other hand. Following list shortly introduces each of the proposed layers along with an example.

• Settings
  Global site-wide preprocessor things like fonts, colors definitions, etc.

$primary-color: blue;

• Tools
  Globally used mixins and functions.

  
    
@mixin border-radius($radius) {
  -webkit-border-radius: $radius;
     -moz-border-radius: $radius;
      -ms-border-radius: $radius;
          border-radius: $radius;
}

  

It is important to mention that the first two layers are only relevant in case you use preprocessors like SASS or LESS. They should not contain any plain CSS code.

• Generic
  Reset and/or normalize styles, box-sizing definition, etc.

  
    
* {
  box-sizing: border-box;
}

  

• Elements
  Styling for bare HTML elements (like h1, a, etc.). These elements should have a site-wide style which can be overwritten by lower levels in the triangle.

  
    
a {
  color: blue;
}

  

• Objects
  Class-based selectors which define undecorated design patterns.

  
    
.one-half-grid {
  width: 50%;
}

  

• Components
  Specific UI components. In this layer of ITCSS you should start to think in styling components instead of styling the page top down.

  
    
.carousel {
  // different styles for a carousel component
}

  

This is where majority of our work takes place and our UI components are often composed of objects and components

• Utilities
  These are helper classes with ability to override anything which goes before in the triangle. Here it is also allowed to use !important since this class should definitely be applied in the specified way.

  
    
.u-hidden {
  display: none !important;
}

  

The cool thing is that ITCSS is flexible and extensible. If you do not use SASS or LESS and stick to plain CSS just skip the first two layers. If you do not need resets, skip the generics layer. In bigger projects it sometimes even makes sense to introduce an additional layer. This can all be done with ITCSS as long as you ensure the inverted triangle to be fulfilled.

Conclusion

No matter whether you start working on a small website or a huge web application, ITCSS promises to introduce tidiness into the jungle of CSS code. Although I have not yet applied ITCSS successfully to different projects, I finally discovered a neat process to manage and scale CSS. A good perspective in my opinion is that you can encourage your co-workers and team members to keep this triangle always in their mind when touching a CSS file. As a result the structural CSS problems should be diminished when using ITCSS consistently throughout a project. I hope I could show you something new with ITCSS and you consider using it when working with CSS next time. If you like to dig deeper into the topic I can recommend the stuff from CSS guru Harry Roberts.