CSS Development Level: A Closer Look at CSS Architecture
We all know that organization, order, and modularity are key to success when working with CSS, and therefore CSS architectures are becoming increasingly popular.
I wanted to try them all to check the pros and cons, and this is what I came with.
Nicole Sullivan’s OOCSS stands for Object-Oriented CSS and aims to encourage code reuse by separating the structure from the outside and the containers from the content. This makes styles modular, scalable and easier to maintain.
OOCSS can be thought of as the pioneer and parent of all other CSS systems. It has more defined a new way of approaching style sheets than a clear system of rules and organizations.
All that was introduced later was actually an evolution of OOCSS, and I think that a number of steps have been taken forward since the release of OOCSS. At present, we can simply take it for granted that an object-oriented method is not the preferred option, it is more necessary for thinking when working with large projects, but this is not enough. So let’s move forward!
Jonathan Snook’s SMACSS means a scalable and modular architecture for CSS. I used SMACSS a lot in the past, and I really fell in love with it because it taught me how to organize my files efficiently so that everyone can easily understand the structure using CSS classification.
SMACSS offers five types of categories (Base, Layout, Modules, States, and Theme) that require us to ask ourselves some questions during the development process, thinking about the actual role that each element plays in the system. It also implies recognition of development patterns, encouraging reuse and code support.
I still adhere to all the principles of separation between the categories Base, Layout and Modules. What I really started to relate differently were primarily media queries.
Harry Roberts’ ITCSS stands for the Inverted CSS Triangle, and its key principle is to split CSS code into several levels based on the specificity level. Certain levels are displayed as an inverted triangle: “Settings”, “Tools”, “Generic”, “Elements”, “Objects”, “Components”, “Trumps”.
What I value most in ITCSS is focused on one of the most complex concepts in cascading style sheets: CSS specifics. In fact, he offers to streamline CSS from general styles to explicit ones, giving a clear direction in specifics and thereby reducing complexity and increasing maintainability.
I also like the practice of using prefixes for each name of the main class (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 it is located inside the source code.
Now I’m used to arranging classes based on their level of specificity, but I prefer to simplify the directory structure in fewer layers, given that Settings, Tools and Generic are abstract levels, and Elements, Object, and Components are all modules.
Thierry Koblenz’s ACSS stands for Atomic CSS and is also known as CSS functionality. Its basic concept is to create high-level and reusable CSS using a low specificity selector system. I suggest you read this Sitepoint article, which correctly explains how it works: Learn about CSS architecture: Atomic CSS
Although ACSS may seem like an easy way to deal with classes with low specificity, I think this can lead to big support issues. Using classes like mt10 and pb10 gives you an idea of the layout of the components, not its real role, so what if the component changes its style? We should probably edit both HTML and CSS. I prefer to work on markup without styles and focus instead on the role that components play in choosing CSS class names.
In addition, I think that nothing restricts us from using more self-describing classes, so I would definitely get rid of name abbreviations and abbreviations to make the code more readable for everyone.
BEM from the Yandex team means Block Element Modifier and its basic concept is to determine the main autonomous objects (blocks, that is, header, footer, menu), their internal parts (elements, that is, the title of the title, menu item) and their status (modifiers, for example, a checked checkbox).
I mention BEM at the end, because it is actually more of a naming convention than a structured CSS architecture methodology, and it can be used in conjunction with every CSS architecture method mentioned earlier. It has been growing in recent years, and I think the main reason is that it provides all team members with declarative syntax for HTML and CSS classes, helping to understand the reason for the class name.
I started trying BEM because I really believe in the importance of setting up a naming convention, but I will never get used to it. I think a lot can be done to simplify the syntax: using two underscores to indicate elements and two hyphens to indicate modifiers is not really user-friendly, and I find it is useless verbose and takes more time than necessary to really achieve clarity. In addition, I cannot find a clear correspondence between the naming convention and the directory structure, and this does not immediately make BEM understandable. In addition, I think that BEM does not really explain how to deal with helpers and thematic classes.
Finally, my last question: “Is there a better CSS architecture system?” I think there is more than one. I just keep experimenting and choosing features that best suit my needs, and so I came up with a CSS architecture that worked better for me.