5 Ways to Build Out a Well-Organized CSS Architecture 

Would we be wrong if we stated that the very “easiness” of writing CSS code is this language's “Achilles' heel”, too? It “lures” you in, it boosts your confidence as a programmer and than... nasty surprise... your web projects gradually turn into unmanageable messes! This is why the need of building out a CSS architecture, that we can organize and structure our CSS codebases by, has rapidly gained importance in developers' community!

And where do you add that there are multiple well through-out methods for you to use for neatly and effectively structuring your CSS files! We've hand picked just 5 of them, “la crème de la creme”.

But before we go on with our CSS organizing techniques, let's “look our enemy in the eye”! Let us highlight the challenges that we're currently facing while trying to effectively managing our CSS projects:

 

• it uses global namespaces, leading to inevitable collisions and leaking styles
   
• it's purely declarative: zero logic and no well structured workflow which would let all the other developers working on the same project know about the state of the project itself
   
• it operates with inheritance: meaning that everything is interdependent and, therefore, highly “fragile”, prone to getting broken  
   

And the list can go on. 

So, now that we've pointed out the obstacles that we need to overcome when it comes to “taming” our load of CSS files into a scalable, easy to maintain CSS architecture (suitable for long-running, large projects, needless to add) let us point out to you the 5 “chaos proofing” methods:

 

1. OOCSS

Which stands for “Object Oriented CSS”.

The whole “philosophy” behind this CSS structuring and planning method revolves around the idea of creating pages/views by putting together multiple CSS objects! CSS objects which are independent from one another (see, the CSS's interdependence issue that we've just pointed out in our list of “drawbacks”).

And when we say “independence” from a CSS code's standpoint, we can only imply that:

 

• design and structure are separated 
• container and content are independent of each other, as well 
   

And this whole “separation of concerns” driving principle has 2 major results:

 

1. the entire “load” of code gets considerably lighter (and this is a tremendous asset if we take large, code-packed web projects into account)
    
2. yet things get trickier the moment one of your Toronto developers tries to apply a change to a certain element's style: not only that the CSS will need to be modified, but classes will have to be added to the markup, as well 
    

2. SMACSS

“Scalable and Modular Architecture for CSS”, a style “guide” (rather than a strict framework) developed by Jonathan Snook.

Now this approach to organizing your CSS code is more than “tempting”: it promises you a lighter code “cargo” and simplified code support.

What more could you ask of a CSS organizer, right?

Moreover, this technique operates with 5 sets of rules:

 

1. base rules: targeting a site's main default elements such as body, HTML, a:hover, input, button etc. They target your CSS assets, too, and “constrain” you to use attribute selectors and HTML tags mostly (and classes, too, but extremely rarely)
    
2. layout rules: which segments a web page into multiple sections including global elements such as header, footer, sidebar, article, defining each one's style too. 
    
3. modules rules: includes reusable blocks, modular elements that you get to use several times on the same web page. Keep in mind, though, to avoid using tag selectors and id for module classes!
    
4. state rules: define the various statuses of those modular elements (e.g. hidden, active, inactive etc.). Moreover, you should know that all these variations get prefixed as following: is-active, is-hidden.
    
5. theme rules: define the design styles, how your modules will look like and they're particularly useful in case of larger sites with shared modules having different layouts throughout the websites.
    

Note: take the SMACSS approach as a guideline rather than as a strict method, or a set of rigid “rules”. As a web developer who'll use this method to build a well-structured, maintainable CSS architecture, you'll still be free to use your own namespaces for your class categories, to display them to your liking and so on. The only “common sense” rule is that of documenting your CSS code, so that all the other developers in your team should easily follow you along.

But this “rule” stands irrespective of the CSS structuring approach that you might decide to adopt, right?

 

3. BEM, An Increasingly Popular Methodology for Building Out a CSS Architecture 

… or “Block Element Modifier”, if you prefer, developed at Yandex!

Expect it to be more prescriptive than SMACSS (for instance). BEM is more than just a set of basic guidelines: it delivers a strict method for you to structure your CSS classes into independent modules!

And speaking of this method, although you'll find multiple variations on it, the basic structure looks like this:

_{.block {}}

.block__element {}

.block--modifier {}

.block__element--modifier {}

 

It's only just “fair” that we presented each one of this structure's components right? 

 

• a block: any object on your site (a menu, a person, a login form)
   
• an element: part of a block performing a certain function in the context of that block only: a login button, a menu item...
   
• a modifier: the way you'll represent the variations of a given block (a search input field having a particular button style, a menu “tailored” to adjust itself to a footer or a sitemap etc.)
   

Key Advantages to Using the BEM Method as a “Backbone” for your CSS Architecture:

 

1. it's perfectly scalable, being a perfect fit for both small and large projects
    
2. it keeps you from nesting selectors (a well-known drawback when it comes to Sass codebases) thanks to its long, descriptive class names
    
3. it enables you to reuse your code: basically it works as a “code container” for you, which turns out to be a major asset especially if you're working on a large project where your team has to move “clusters” of CSS, JS and HTML code from one project to another
    
4. it's ideally suited for large, modular web development projects
    

4. Atomic CSS

… or maybe you prefer “Functional CSS” instead?

As for this CSS “organizer's” philosophy, so to say, we could formulate it like this: creating one separate, single-purpose class for each and every reusable property, while naming it according to its visual function!

The undeniable advantages of such an approach to organizing your CSS code are:

 

• a significantly lighter load of CSS code, since you'll get “empowered” to reuse your declarations
• an easy way to modify code (it makes applying changes to your modules less complex, for instance)
   

Yet, this method does come with its own flaws, too. Here are some of the most “painful” ones:

 

• the class naming conventions come along with a high learning curve, too
   
• it makes the style code closely linked to the Atomic CSS framework used for generating the classes
   
• the class names aren't semantically linked to the elements, but rather describe property names 
   
• the display settings are in the HTML
   
• as new CSS modules get added to the specifications, everything gets overly complex 
   

Note: Atomic CSS has “succeeded” to split developers' community into 2 major groups: those that keep highlighting this methodology's major flaws and those that, on the contrary, qualify specifically these flaws as benefits instead:

 

1. the “semantic nature” of the elements are, in their opinion, already properly described by the element tags and your components' names
    
2. the fact that the settings are displayed in the HTML might turn out to be more convenient: this way you won't need to go through your entire maze-like CSS codebase to find out what settings are defined there
    

5. ITCSS: Build Your Manageable CSS Architecture for Large Projects

Harry Roberts' “Inverted Triangle CSS” implies, as the name suggests: visualizing and structuring your project as a triangle. An upside-down one!

This triangle-shaped structure would include the following “layers” of CSS code:

 

• Settings
• Tools
• Generic
• Elements
• Objects Components
• Trumps
   

Practically, the IRCSS technique “constrains” you to order your CSS codebase not by the usual human-oriented patterns, but by those metrics defined by the programming language (along with its particularities) itself!

Ordered this way, your code will get better “understood” and “exploited by both browsers and by the specific design of the programming language itself. It will no longer get organized by how a person thinks, but rather adapted to the language's own features and to the way browsers perceive it.

This way, your ITCSS-based CSS architecture will end up to be:

 

• easily scalable
• logical
• manageable 
• predictable
• rule-based
   

... instead of an “untamed mess”! 

Which one of the above presented 5 methods better suits your team's coding style? Your current project's specific needs and requirements? Go for the one that you find more suitable for your own team's specific workflow, coding style and for your web project's particularities and get your own “unmanageable CSS mess” ideally structured, too!