State of the art in CSS: a closer look at CSS architecture systems

We all know that organization, order and modularity are a success key when dealing with CSS and this is why CSS architecture systems have grown more and more in popularity.

I wanted to try them all to check out pros and cons and that’s what I came up with.

OOCSS by Nicole Sullivan stands for Object Oriented CSS and aims to encourage code reuse through the separation of structure from skin and containers from content. This makes the style modular, scalable and easier to maintain.

OOCSS can be considered as the pioneer and the parent of all the other CSS systems. It has moreover defined a new way of approaching stylesheets rather then a clear system of rules and organization.

Everything introduced later was actually an evolution of OOCSS and I think a bunch of steps forward have been made since the first time OOCSS was launched. Nowadays we can just take for granted that the object-oriented method is no more an option, it’s more a needed mindset when dealing with big projects, but it’s not enough. So let’s move forward!

SMACSS by Jonathan Snook stands for Scalable and Modular Architecture for CSS. I had been using SMACSS a lot in the past and I really fell in love with it because it taught me how to efficiently organize my files in a way that everyone could easily understand, through CSS categorization.

SMACSS suggests five types of categories (Base, Layout, Modules, States and Theme), which require us to ask ourselves some questions during the development process, thinking about the actual role that each element plays in the system. This also implies the recognition of development patterns, encouraging code reuse and maintenance.

I’m still adopting all the principles behind the separation between Base, Layout and Modules categories. Instead, what I started to handle differently was states and media queries above all.

ITCSS by Harry Roberts stands for Inverted Triangle CSS and its key principle is the separation of the CSS codebase into several layers, based on the specificity level. The defined layers are displayed as an inverted triangle: Settings, Tools, Generic, Elements, Objects, Components, Trumps.

What I appreciate most of ITCSS is its focus on one of the most tricky concepts in cascading stylesheets: the CSS specificity. In fact, it proposes to order the CSS from generic styles to explicit ones, giving a clear direction in specificity and so reducing complexity and increasing maintainability.

I also like the practice of using prefixes for each major class name (o- for objects, c- for components, and u- for utilities). This gives the developer a clear idea of what each class is used for and where exactly it’s located inside the source code.

Now I’m used to ordering classes basing on their specificity level, but I prefer to simplify the directory structure in fewer layers, considering that Settings, Tools and Generic are all abstract levels and Elements, Object and Components are all modules.

ACSS by Thierry Koblenz stands for Atomic CSS and it’s also known as Functional CSS. Its core concept is to create highly granular and reusable CSS, by using a system of low-specificity selectors. I suggest you the reading of this article by Sitepoint, which properly explains how it works: Learn about CSS Architecture: Atomic CSS

Although ACSS may seem a simple way to handle with low-specificity classes, I think it may lead to bigger maintainability issues. Using classes like mt10 and pb10 gives you an idea about the component makeup rather than its actual role, so what if a component change its style? We should likely edit both HTML and CSS. I prefer by far to work on a style-agnostic markup and keep focused instead on the role played by components when choosing the CSS class names.

Besides, I think that nothing limits us to use more self-explanatory classes, so I’d definitely get rid of name abbreviations and acronyms in order to make the code more readable to everyone.

BEM by the team at Yandex, stands for Block Element Modifier and its core concept is to identify the main standalone entities (the blocks, i.e. header, footer, menu), their inner parts (the elements, i.e. header title, menu item) and their states (the modifiers, i.e. disabled checkbox).

I’m mentioning BEM at the end because it is actually a naming convention more than a structured CSS architecture methodology, and it can be used in conjunction with each CSS architecture method mentioned before. It has been on the rise in recent years and I think the main reason is that it provides everyone in the team with a declarative syntax for HTML and CSS classes, helping to understand the reason behind a class name.

I started trying BEM because I really believe in the importance of setting a naming convention, but I never actually got used to it. I think that a lot can be done to simplify the syntax: the use of two underscores to denote elements and two hyphens to denote modifiers is not really user friendly, I find It to be needlessly verbose and requiring more time than necessary to really get into it. Also, I can’t find a clear correspondence between the naming convention and the directory structure, and this may contribute to make it not immediately understandable. Also, I think that BEM does not really clarify how to deal with layout, helpers and theme classes.

Finally, my last question is: “Is there a best CSS architecture system?” I think there isn’t just one. I just kept experimenting and picking the features that best suits my needs and so I came up with the CSS architecture that more worked for me. I will deep dive into the details later in my next article.