Tips for organizing your CSS

By Nicholas Rougeux, posted on September 10, 2006 in CSS, Web

The most frustrating part for me when it came to learning CSS trying to figure out what parts of the style sheet affected which parts of the site and why. I think managing someone else's style sheet is one of the hardest things to do when maintaining a site simply because you don't know what that other person was thinking when they created it. Everyone has a different mindset. However, if people organize their style sheets coherently, managing them is a lot easier. Sure, many of the style sheets I saw had styles grouped by the sections of the site to which they applied, but it was more still disorganized.

For the past few years I've developed the following techniques that have made managing CSS easier and much more efficient.

Group styles by meaning

Every style sheet I create starts with the same core structure comprising the following groups:

  • Undo existing styles—Browsers render default styles differently, so taking advice from Tantek Çelik, one of the CSS gurus, I use this section to reset most of the default styles that vary between browsers so they're consistent and so I don't have to worry about creating additional browser-specific style sheets.
  • Basics—The basics of a site include all elements without classes or IDs. It's the place to specify the main styles that apply to most of the site instead of specific areas like on the body, anchors, headings, tables, lists, etc.
  • Fonts—Instead of defining the same font family multiple times throughout style sheets, designate a section just for font families. I group selectors within this section based on the font family. For example, I would list all of the selectors targeting elements that need the Georgia font and apply one declaration to all of them. This reduces the number of times I need to use the same font family and makes changing it much easier.
  • Core layout—Separating the styles that define the core layout of the site—such as columns, background colors, and the positioning of the main sections—from those that define the smaller areas makes style sheet management much easier. I try to define only the major elements such as the header, footer, and content areas and only the declarations such as display, width, margin, padding, positioning, background, and float.
  • Content—This is where most of the styles defining the finer points of Web sites are defined and grouped into subgroups according to how they apply to various parts of the sites.

I use these same groups on the style sheet for this site and I include a line of about 70 equal signs underneath each to help identify where the groups are. These long lines help when viewing style sheets with or without syntax highlighting. They stand out even more with the highlighting so they're very helpful.

Within these groups are additional groups indented for each level of subgrouping. Indenting allows you to quickly identify which groups of styles relate to each other. Each level has a different type of header to denote its level. The style of creating the headers I chose was based on how easy it was to type quickly. Fortunately, the opening and closing markers for comments are close to each other on number pad on the keyboard so I chose to use the other symbol right next to them—the hyphen, or dash.

The three styles of headings I use are:

  1. /* Level 1
  2. /*--- Level 2 ---*/
  3. /* Levels 3, 4, 5, etc. */

Second level headings have a space and three dashes before and after the text so they stand out more than subsequent levels but not too much so they don't compete with the main headings. Additional groupings at lower levels just use the normal opening and closing comment text. I rarely need to group styles into more than three levels and if I do, the indentation is enough to show how its related to others.

Alphabetize just about everything

I like to stay organized and the easiest way to do that is to keep everything alphabetized with the exception of the core groupings I described above which are organized in order of importance and size. The first few are usually smaller containing just a few rules while the last few contain many more. Aside from those, I alphabetize everything including individual declarations like background, color, margin, etc. and entire rules for different areas of sites.

Some people prefer to organize declarations by grouping them by likeness such as height and width, margin and padding, font and color, etc. If this works for you, that's great. I find it easier to alphabetize all properties so I know where how to find declarations that need to adjusting them without having to remember which are similar and why. If I need to adjust the background color and the width, I know to look at the beginning and end of the list right away.

The same principle applies to organizing groups of styles. For example, on for this site, some of my content style groups are for the gallery in the portfolio, the navigation, and the comments. Therefore, they're organized in the order of Comments, Gallery, then Navigation. As long as I use names that are simple and intuitive, it's easy to find them later on. Some choose to order them by how they appear on their site and there's nothing wrong with that. I prefer this way because if at some point the site is redesigned or updated and sections are moved around, I don't have to worry about how they're ordered in the style sheet.

Write legible styles

Part of the frustration when learning CSS came from not being able to read others' style sheets easily and this came from either not being able to decipher their method of organization or because they were created automatically with a program. Programs tend to create style sheets with each declaration on its own line regardless of how many there are. This leads to a lot of unnecessary white space and a very long style sheet. Those just starting out with CSS often begin by creating style sheets with programs and when they learn to do it by hand, they mimic this style when writing their own CSS. I'm just as guilty of this as the next person.

If there's only one, two or three declarations in a rule, there's usually no reason to add a new line for each one. Keeping them on one line is still readable and saves space. Now, if there are many declarations it makes much more sense to put each on their own line. There's a balance you need to find. What do you find easiest to read? One line? Two? Both? I prefer to mix and match. I don't want my one-liners to be too long so I usually maintain a soft rule of not creating lines in my style sheet much wider than the first level of headings. This means that lines are usually no longer than 100 characters or so.

Everyone has their own style and methods of organization that works for them. The techniques I've described have evolved from working on many different sites over the years, ranging from small and simple large and complex. I organize my style sheets so that anyone interested can look at them and understand what I did and why. These people don't include just my coworkers but anyone else looking to learn something new about CSS.

« Back to blog