For frontend developers like myself, it’s safe to say that modern-day websites are big, and CSS is weak. Its global scoping and odd property interactions just don’t lend well to DRY (don’t repeat yourself) code, meaning that CSS files often balloon to incredible, unmaintainable sizes.
CSS architectures were created in a desperate bid to insert sense into a senseless language. Keep in mind that when I say “CSS Architectures”, I don’t mean premade style systems or libraries, like Bootstrap. I’m referring to a more philosophical agreement on how to organize and name classes to minimize insanity. In this article, I will lay out some examples of the most popular CSS Architectures and highlight the differences in how they are used.
CSS Architectures Commonalities
All CSS Architectures have these three things in common:
- Make CSS as consistent as possible
- Make code reusable and lower unmanageable bloat
- Be efficient
There are as many different architectures as there are opinions, but in the end, they just approach the above commonalities in wildly different ways. To highlight the differences in method, I’ve cooked up an example block coded in ‘normal css’ here:
Object-Oriented CSS
Object-Oriented CSS (OOCSS) was originally proposed by the web developer Nicole Sullivan in 2008. She thought that applying object-oriented principles to CSS, like those found in JAVA or Ruby, would make it more flexible, more modular, and easier to manage. OOCSS has two major principles:
- Separation of structure and skin
- Separation of container and content
Structure and Skin is referring to styles that impact the layout of things (padding, margin, display, etc.) versus the styles that impact branding-related elements, such as colors and fonts.
Separating container and content means that location-specific styles should be avoided as much as possible. If we took our example block above and applied OOCSS to it, it would look like the following:
Pros: Modular, Flexible, Reusable, and Scales Well
Cons: Big learning curve, and can bloat classes and HTML
BEM or Block, Element, Modifier
Block, Element, Modifier (BEM) was created by the Russian company Yandex. BEM separates the site into visual components, or blocks, that contain smaller parts, called elements. If there are two versions of a certain block or element, like with buttons, then the classes are modified with a modifier. In the end, the classes would be written like the following:
If we were to rewrite our example code, it’d look like this:
Pros: Great with component-based systems, takes away the mental burden of naming classes, and very popular
Cons: long and ugly classnames and styles will repeat if components are visually similar
Atomic/Functional CSS
Atomic CSS and Functional CSS (not to be confused with Atomic Web Design, a totally separate thing) are interchangeable names for a term created by Thierry Koblenz in his 2013 article “Challenging CSS Best Practices”.
In this article, Koblenz boldly states that the most reusable and readable way to create CSS would be to have one style associated with each class. Since each class corresponds with a style, this would essentially be styling via markup. Let’s go back to our example:
Pros: Very easy to name classes, no need to worry about specificity, and can just decode/debug CSS by looking at HTML
Cons: Huge learning phase, goes against everything previously taught about CSS, globally changing the styles of an element would require a search and replace in the HTML, and may require an additional processor to generate styles for ease of use
Scalable and Modular Architecture for CSS and Inverted Triangle CSS
Both Scalable and Modular Architecture for CSS (SMACSS), created by Jonathon Snook, and Inverted Triangle CSS (ITCSS), created by Harry Roberts, are approaches aimed less at the class names and more at CSS folder/file organization, which is why they’re both grouped in a single section. They both take a general “embrace the cascade” approach to organizing files, from most general to most specific.
The groupings for SMACSS are split into the following:
- Base: default styles (html, body, etc.) and reset/normalizing styles
- Layout: pages and page sections
- Module: reusable elements
- States: element variations (active, inactive, checked etc.)
- Theme: the branding or skin on top (colors, type, etc.)
ITCSS renames and adds a few more categories:
- Settings: font/color/etc variables for preprocessors
- Tools: mixins and functions for preprocessors
- Generic: reset/normalizing styles
- Elements: base tag styles (h1, a, buttons, etc.)
- Objects: Abstract, layout-type styles, similar to the structure in OOCSS
- Components: specific UI components, most code will be contained here
- Trumps: utilities and helper classes that can override all previous styles
I find that these methods are less standalone and more useful for file organization for the other architectures mentioned above.
Choose a CSS Architecture Methodology That’s Best for You
The debate on the best architecture can get pretty heated in frontend circles! However, I think everyone can agree that choosing any methodology and being consistent throughout the project is more important than finding the “best” option. For my personal projects, I prefer a combination of ITCSS organized files using BEM and a more OOCSS-type utility class.
Are you looking for more information on these CSS Architectures or do you want to know more about commonly used front-end development methods? Contact us today and one of the talented members of our custom development team will be in touch!
