How should I organize the contents of my CSS file(s)?

Solution 1:

Have a look at these three slideshare presentations to start:

• Beautiful Maintainable CSS
• Maintainable CSS
• Efficient, maintainable, modular CSS

Firstly, and most importantly, document your CSS. Whatever method you use to organize your CSS, be consistent and document it. Describe at the top of each file what is in that file, perhaps providing a table of contents, perhaps referencing easy to search for unique tags so you jump to those sections easily in your editor.

If you want to split up your CSS into multiple files, by all means do so. Oli already mentioned that the extra HTTP requests can be expensive, but you can have the best of both worlds. Use a build script of some sort to publish your well-documented, modular CSS to a compressed, single CSS file. The YUI Compressor can help with the compression.

In contrast with what others have said so far, I prefer to write each property on a separate line, and use indentation to group related rules. E.g. following Oli's example:

#content {
    /* css */
}
    #content div {
        /* css */
    }
    #content span {
        /* css */
    }
    #content etc {
        /* css */
    }

#header {
    /* css */
}
    #header etc {
        /* css */
    }

That makes it easy to follow the file structure, especially with enough whitespace and clearly marked comments between groups, (though not as easy to skim through quickly) and easy to edit (since you don't have to wade through single long lines of CSS for each rule).

Understand and use the cascade and specificity (so sorting your selectors alphabetically is right out).

Whether I split up my CSS into multiple files, and in what files depends on the size and complexity of the site and the CSS. I always at least have a reset.css. That tends to be accompanied by layout.css for general page layout, nav.css if the site navigation menus get a little complicated and forms.css if I've got plenty of CSS to style my forms. Other than that I'm still figuring it out myself too. I might have colors.css and type.css/fonts.css to split off the colors/graphics and typography, base.css to provide a complete base style for all HTML tags...

Solution 2:

I tend to orgainize my css like this:

1. reset.css
2. base.css: I set the layout for the main sections of the page
   1. general styles
   2. Header
   3. Nav
   4. content
   5. footer
3. additional-[page name].css: classes that are used only in one page

Solution 3:

There are a number of recognised methodologies for formatting your CSS. Its ultimately up to you what you feel most comfortable writing but these will help manage your CSS for larger more complicated projects. Not that it matters, but I tend to use a combination of BEM and SMACSS.

BEM (Block, Element, Modifier)

BEM is a highly useful, powerful and simple naming convention to make your front-end code easier to read and understand, easier to work with, easier to scale, more robust and explicit and a lot more strict.

Block

Standalone entity that is meaningful on its own such as:

header, container, menu, checkbox, input

Element

Parts of a block and have no standalone meaning. They are semantically tied to its block:

menu item, list item, checkbox caption, header title

Modifier

Flags on blocks or elements. Use them to change appearance or behavior:

disabled, highlighted, checked, fixed, size big, color yellow

OOCSS

The purpose of OOCSS is to encourage code reuse and, ultimately, faster and more efficient stylesheets that are easier to add to and maintain.

OOCSS is based on two main principles:

1. Separation of structure from skin

This means to define repeating visual features (like background and border styles) as separate “skins” that you can mix-and-match with your various objects to achieve a large amount of visual variety without much code. See the module object and its skins.

2. Separation of containers and content

Essentially, this means “rarely use location-dependent styles”. An object should look the same no matter where you put it. So instead of styling a specific with .myObject h2 {...}, create and apply a class that describes the in question, like . This gives you the assurance that: (1) all unclassed s will look the same; (2) all elements with the category class (called a mixin) will look the same; and 3) you won’t need to create an override style for the case when you actually do want .myObject h2 to look like the normal .

SMACSS

SMACSS is a way to examine your design process and as a way to fit those rigid frameworks into a flexible thought process. It is an attempt to document a consistent approach to site development when using CSS.

At the very core of SMACSS is categorization. By categorizing CSS rules, we begin to see patterns and can define better practices around each of these patterns.

There are five types of categories:

/* Base */

/* Layout */

/* Modules */

/* State */

/* Theme */

Base Contains reset and default element styles. It can also have base styles for controls such as buttons, grids etc which can be overwritten later in the document under specific circumstances.

Layout Would contain all the navigation, breadcrumbs, sitemaps etc etc.

Modules Contain area specific styles such as contact form styles, homepage tiles, product listing etc etc etc.

State Contains state classes such as isSelected, isActive, hasError, wasSuccessful etc etc.

Theme Contains any styles that are related to theming.

There are too many to detail here but have a look at these others as well:

• SuitCSS
• AtomicCSS (not Atomic Design)
• oCSS (organic CSS)

Solution 4:

However you find it easiest to read!

Seriously, you'll get a billion and five suggestions but you're only going to like a couple of methods.

Some things I shall say though:

• Breaking a CSS file into chunks does help you organise it in your head, but it means more requests from browsers, which ultimately leads to a slower running server (more requests) and it takes browsers longer to display pages. Keep that in mind.
• Breaking up a file just because it's an arbitrary number of lines is silly (with the exception that you have an awful editor - in which case, get a new one)

Personally I code my CSS like this:

* { /* css */ }
body { /* css */ }
#wrapper { /* css */ }
#innerwrapper { /* css */ }

#content { /* css */ }
#content div { /* css */ }
#content span { /* css */ }
#content etc { /* css */ }

#header { /* css */ }
#header etc { /* css */ }

#footer { /* css */ }
#footer etc { /* css */ }

.class1 { /* css */ }
.class2 { /* css */ }
.class3 { /* css */ }
.classn { /* css */ }

Keeping rules on one line allows me to skim down a file very fast and see what rules there are. When they're expanded, I find it too much like hard work trying find out what rules are being applied.