CSS

6 Ways to Organize Your CSS

So you’re getting started with CSS, and you’re having a little trouble keeping it organized. Well, CSS has an inherent organization method that is right in the name: The Cascade. Whatever you write first will impact everything that comes after it; and it can all be overridden where needed. That, of course, is predicated on the idea that you’re building a small, static HTML site in 1998-to-early-2000s.

Those were the days. Get off my lawn.

Don’t get me wrong. The Cascade is as important as ever, and still incredibly powerful. It’s just that websites have gotten more complicated. Front-end developers often write thousands of lines of CSS for an individual project. Keeping all of that code organized can become a task so monumental, that devs have created entire systems and even apps dedicated to organizing it all.

Whatever tools you use, you need something. Writing just one big-old stylesheet will work just fine for your one-page portfolio, or maybe even for a five-page brochure site. It’s unlikely to work for anything more complex.

1. Use a CSS Pre-Processor

Just about every guide to organizing your CSS starts here, and for good reason: it lets you put everything into one big-old stylesheet. Yes, I know what I just said above; hear me out. The more CSS files you link to in your HTML, the more HTTP requests your browser makes. This slows things down a bit. At the very least, it’s more work for the processor. The @import rule in regular CSS has the same problem.

With a pre-processor, you can separate your CSS into as many different files and folders as you need (more on that next), and compile them all into one file for the browser when you save. It’s the best of both worlds. I would recommend starting a test project with Sass (currently the most popular CSS pre-processor) to get a feel for how it works.

2. CSS Files for Individual Pages

Here’s a tip for smaller sites: have a separate CSS file for every page. This is especially useful on those sites where every page has a different layout. The simple fact that you don’t have to scroll past the CSS for other pages when looking for the CSS you want is a huge productivity boost. Working on the “About Page”? Just open about-page.css and go.

3. CSS Files for Complex and Repeating Components

Now this works the same for smaller and larger sites: if you have something that is complex — like a fancy slideshow on the home page — give it its own CSS file. Do not put it in the same CSS file as your home page. The same goes for any elements you might use on more than one page: the header, the navigation, the footer, an image gallery, or what-have you.

It’s not just about organizing your code. If you keep the code for these elements separate and independent from any page-specific styles, it’s easier to reuse them. Speaking of which:

4. Break it Down Further

Coding CSS for large, complex sites (think ecommerce, or something similarly huge) is tough. Coding them in a team is a whole different ballgame. If you’re even going to consider something like this, you’re going to need a whole new way of thinking about design. The methodology I’d recommend is called Atomic Design.

It breaks down design elements into five categories:

  1. Atoms
  2. Molecules
  3. Organisms
  4. Templates
  5. Pages

Atoms are individual elements like buttons, text fields, and so on. In this example, Molecules would be like a form made of the text inputs and buttons. Organisms are larger collection of molecules like a page header, and so on.

How does this relate to CSS? You can write your CSS in much the same way: focus on the atoms first. Have a stylesheet dedicated to the basic styles for forms. Another for basic typography. Heck, I do that in smaller projects, too. Then you can create separate stylesheets for Organisms, and even for some more complex Molecules.

It’s a lot of separate CSS files; but the faster you can find the code you want to work on, the better.

5. Avoid Class-itis

What is class-itis? It’s a terrible disease that forces the user to use the class= attribute like the style= attribute. The poor souls who have this disease are basically replicating the way we used to do things in the days of table layouts. Their code looks a bit like this:

<div class="red-bg corners-rounded-5px columns-3 height-flexible helpme icantgoonlikethis">[Insert content here]</div>

It’s very sad. And worse, this disease can be transmitted by some of the larger CSS frameworks, and even some CSS methodologies (which is one reason I’m not addressing them, much). Look, no matter what attribute you’re using, if you’re writing your styles in the HTML files, you’re doing it wrong. It’s unmaintainable, especially as sites get larger.

6. Minimize Depth

Now here’s where I mention the one CSS methodology I actually like: SMACSS. Here’s an idea straight from them that illustrates why: depth of applicability.

Now what the heck does that mean? Well remember how I said to avoid using too many classes? Well if you take that too far and try to avoid using them at all, you’ll end up a nearly unreadable mess of duplicated CSS rules, like so:

header nav ul, footer nav ul, aside div ul {margin-top: 1rem;}

Not only is that a fair bit of CSS, the CSS is non-specific enough that it could affect other parts of the design way too easily. You could just use a class to avoid all that:

.molecule-nav {margin-top: 1rem;}

As you can see, there’s a balance to be struck between having too many classes, and not enough. Read more about this concept on the official site.

Ezequiel Bruni is a web/UX designer, blogger, and aspiring photographer living in Mexico. When he's not up to his finely-chiselled ears in wire-frames and front-end code, or ranting about the same, he indulges in beer, pizza, fantasy novels, and stand-up comedy. More articles by Ezequiel Bruni
  • Gustavo Reis

    Hi Ezequiel, do not forget of suggesting that we have a separate JavaScript file for every page. For example, Bootstrap and Bootstrap offers separate SCSS files and separate JavaScript files and we compile only selected SCSS files.

    As I do not want to use JavaScript files and codes for optimising the site and keeping it faster to load, I remove some SCSS files which require to use JavaScript from bootstrap.scss and materialize.scss.

    I use another programming language to reutilise automatically and unify three files – metadata and scripting, heading and footer, on each page for resynchronising the CSS files and JavaScript files, and after put a separate CSS files after heading, and put a separate JavaScript file before footer which is before </body>.

Home CSS Deals HTML HTML5 Java JavaScript jQuery Miscellaneous Mobile MySQL News PHP Resources Security Snippet Tools Tutorial Web Development Web Services WordPress