5 Steps to a More Organized Style Sheet

Published March 3, 2008 by Rob Glazebrook.

organized bookcase

One of the nice things about languages like CSS is that you don’t have to write them in any specific way. For example, you could place all the CSS rules for your entire website on a single line of text, and assuming you had some brackets and semicolons stuck in there at appropriate intervals, your website would render without a hitch.

Of course, finding a single, specific rule in that amalgam of CSS soup would be a bit difficult, and that starts to negate the benefits of using CSS in the first place. Luckily, we have the opportunity to use the flexibility inherent in writing CSS for good instead of evil (or at least preparedness instead of poor planning). Here are a few tips that can make your CSS much easier to read – and therefore edit – in the long run.

Pick a Formatting Style

When I’m writing example CSS for someone to follow, I tend to use a more traditional formatting for my rules, like so:

body {
	font-size: small;
	color: #333;
}
p {
	margin: 1em 0;
}

However, for all its ubiquity, I don’t really care for this style. My eye tends to get distracted by the closing bracket on a line all by itself, and I consider it a bit wasteful to spend an entire line to say, “Okay, I’m done now,” when CSS lets us put that bracket wherever we darn well please. So when I write CSS for my own projects, I write it like this:

body {
	font-size: small;
	color: #333;}
p {
	margin: 1em 0;}

The only real change here is that I’ve moved the closing brackets up to the preceding line, but it helps me a lot. Now my eye knows that anything in the far left is a selector, and anything indented is a property. I’ve also saved myself two lines of code. Now, I’m not saying this style is right for everyone, but the main idea here is to find a style that works well for you and stick with it. Once your eye gets used to seeing your CSS written in a specific way, scanning your code gets a lot easier.

Section Your Code

CSS has built-in comment tags, which look like this:

/* This is a comment! */
p {
	margin: 1em 0;}

Anything that appears before the opening comment tag and the closing tag, no matter how many lines it spans, is considered a comment. These little tags are great for putting up little notes to define sections of your code. I personally use comments as heading tags to define sections of my website. For example, I might have one section titled /* Sidebar */, where I put all of my sidebar-related styles, or one called /* Article */, where all my article-specific CSS resides.

You can get as general or as granular as you want or need with this technique, depending on the size and complexity of your stylesheet. If I’m the only one who’s ever likely to edit the CSS, I tend to get away with fewer comment tags than I would if I knew that other people would be trying to decipher my code.

Use a Table of Contents

If you end up creating a massively large and complex stylesheet, containing several hundred or even a couple thousand lines of code, simply breaking that code up into a dozen or so sections might not be enough. On my biggest projects, I tend to create a Table of Contents at the top of my CSS to help me remember how my CSS is organized, and help me (or someone else) find things later on down the line. A table of contents might look something like this:

/* Table of Contents:
	1. Reset Styles
	2. Baseline (Default) Styles
	3. Column Structure
	4. Main Column (articles, etc)
	5. Comments and Pingbacks
	6. Sidebar lists and Ads
	7. Footer 
*/

Then you can just insert appropriately named comment headings along the way to help you or someone else make their way through your document. Scanning code gets a lot easier when you know you’re looking for section #5 and that there will be a comment tag to let you know when you’ve arrived.

Group Selectors with Common Values

Let’s say you have five levels of heading tags in your articles, h1 – h5. They are all rendered in Verdana, but at different sizes and colors. Obviously, you’re going to need more than once rule to style all these elements, but that isn’t to say you can’t group their common attributes together. For example, instead of writing this:

h1 {
	font-family: Verdana, sans-serif;
	font-size: 200%; }
h2 {
	font-family: Verdana, sans-serif;
	font-size: 175%;
	color: #333; }
h3 {
	font-family: Verdana, sans-serif;
	font-size: 150%;
	color: #f00; }
/* And so on… */

You could make everything a lot cleaner and easier to edit in the future by writing this instead:

h1, h2, h3, h4, h5, h6 {
	font-family: Verdana, sans-serif; }
h1 {
	font-size: 200%; }
h2 {
	font-size: 175%;
	color: #333; }
h3 {
	font-size: 150%;
	color: #f00; }
/* And so on… */

Group Default Styles

Mike Rundle of BusinessLogs recently argued that using default styles (for example, styling all your anchor tags at once) is counter-productive, because when an element isn’t behaving like you’d expect it to later on down the line, you can spend a lot of time trying to “fix” your code unnecessarily because you’ve forgotten about a default style you’d set previously.

I agree to a point: I would say that you shouldn’t overly style general elements. Don’t style your anchors as bright red with a dotted border unless 99% of your links are going to appear that way. However, if none of your links in your entire site are going to have an underline, I don’t see the harm in removing the underline from your anchor tags. Because here’s the important thing to remember: all browsers have a default style sheet. Even if you don’t apply a single style to your anchor tags, they’re going to have a style (blue, underlined) to begin with. Using default styles is a means of establishing a baseline more conducive to your overall site goals.

But you can make your life a little easier by grouping all of your default styles. I tend to put them all up at the top of my document, labeled with a comment-header. That way, if (to continue the example) my anchor tags aren’t behaving like I expected a few hundred lines of CSS later, I can just check really quick to make sure my default styles aren’t interfering in some unexpected way (but since they’re only baseline styles, that’s rarely the case).

These are just five tips that have helped me keep my CSS a bit more organized. Do you have any tips that have helped you streamline your CSS?

7 Responses

  1. Tina Russell (reply)

    I found your blog on google and read a few of your other posts. I just added you to my Google News Reader. Keep up the good work. Look forward to reading more from you in the future.

    Tina Russell

  2. Scott Phillips (reply)

    You said that you create a table of content when your style sheets get hundreds or thousands of lines long. I’ve seen sites that break the css into separate files such as: reset.css, typography.css, layout.css, etc. Do you see any value in approaching the organization that way instead?

  3. Rob Glazebrook (Author) (reply)

    Good observation, Scott. I’m hoping to cover that technique in a future article. :)

    I personally rarely use that technique, however, because I don’t tend to think of my websites as organized according to typography vs. layout. I see a “sidebar” (for example) as a cohesive unit, with its own layout and typographical considerations. I quickly get annoyed when I want to bump up a header size by a few percentage points and move it by a couple of pixels, and that requires me to edit more than one style sheet.

  4. Custom Wordpress Designs (reply)

    I use the table of content section at the top of the css file to also add when the file was created and the last time it was edited, my email address, ect. This way, a client has all of that information right there in case they run into a problem. Something like below:

    /* Table of Contents:
    File Created: March 11th 2008
    File Last Edited: March 13th 2008
    File Creator: Mike Smith
    Contact File Creator: myemail@address.com
    */

  5. Pingback: 15 Surefire Ways to Break Your CSS

  6. Pingback: 15 Surefire Ways to Break Your CSS « Internet Turnkey Websites

  7. Pingback: STC Rocky Mountain Chapter - Newsletter » Blog Archive » Organizing Cascading Style Sheets

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>