The Third Degree

Formatting CSS: File Structures to Property/Value Pairs

Many developers have their own way of formatting or structuring their code when developing, but when working with a team of developers, one standard way of formatting and structuring code is in everyone's best interest. 

Over the years, I have thought a lot about the way I structure my CSS from the file structure down to the order in which I place the properties/values. My methods are not perfect by any means. So pick them apart and let me know your thoughts...

File Structure

For the average web site I keep my file structure pretty simple, but for more complex sites, like ecommerce sites, I tend to break things into more specific pieces. For example, an average size web site (3-10 template pages) I usually go with 3 main CSS files, not including the IE specific file. I name them:

• defaults.css
• layout.css
• presentation.css

defaults.css: I usually do all of my default styling and simple work-around classes within this file. For example, setting an image border to "none" when inside of an anchor element. And, setting the form element to have a "0" margin and padding.

layout.css: Within the layout.css file, I place all of my structural page elements, usually referenced by id, in the same order as they are in within the HTML template.

presentation.css: All of the presentational styling for the site is contained within this one file.

And in the rare case (ha!) that I need IE specific styles, I will also have an ie.css file that is included in the template using a conditional comment (see below).

<!--[if IE]>
<link href="/css/ie.css" rel="stylesheet" type="text/css" media="all" />
<![endif]-->

These files are included into each HTML template in the order listed.

In the case of a larger web site, like an ecommerce site, I tend to have the same base CSS file structure and then include section specific CSS files after the base CSS files so if needed I can overwrite the default styling. For example, if I was developing a template for an ecommerce system I would most likely have the following files, included in this order:

• defaults.css
• layout.css
• presentation.css
• shopping.css - for any browse/search pages (conditionally included)
• myaccount.css - for the my account section (conditionally included)
• checkout.css - for the checkout process pages (conditionally included)
• ie.css

This structure allows me to set all of my default "look and feel" styles, and then style the more section specific elements for each section of the site. After developing a number of ecommerce sites, I've found that this method is very useful because each section of the site often contains many different elements than the other sections. This also helps keep the CSS files down to a reasonable size.

Selector Structure

For each CSS file that I write, I get a little bit better at keeping my selector structure more organized. When I say selector, I'm referring to each element (h1, h2, p, li), id (#foo, #bar), or class (.foo, .bar) used within a file. Structuring or organizing your selectors in a specific order helps other developers, who need to edit the code, find what they are looking for more easily. Yes, they could just use the "search" feature within their code editor, but keeping selectors organized helps when tracking down those 4 pixels getting inherited only in IE6.

Within the defaults.css file, I usually keep it simple. It's not a lengthy file, so I usually start with body and work my way down the hierarchy of elements, then my work-around classes at the bottom.

Layout.css follows the same structure of the HTML template, starting with body then the outer most header element, and ending with the inner most footer element. For example, if I had 3 container <div>'s, named header, content, and footer my CSS would look like this:

body {
    margin:0;
    padding:10px 0;
}
#header {
    display:block;
    margin:0 auto;
    padding:4px 10px;
    width:740px;
}
#content {
    display:block;
    margin:0 auto:
    padding:10px;
    width:740px;
}
#footer {
    display:block;
    margin:0 auto;
    padding:10px;
    width:740px;
}

I also prefer to keep my opening curly bracket on the same line as my selector, and then use 1 tab in front of each property/value pair, and then on a new line place my ending curly bracket. For me, this helps when looking for a particular selector, I can scan down the page and only read the first few columns and my eye knows where each selector starts and ends - making it easier/faster to find what I'm looking for.

With the presentation.css file, I take a whole different approach. I structure my selectors based on certain criteria as opposed to in what order they fall within the HTML, because most styles could be used multiple times throughout the page. With each site that I build the structure is a little different, but for the most part elements are grouped together based on their relevance to each other and the HTML page. Here's an example of what types of selectors I would group together and in what order:

• Structural element styling (body, #header, #content, #footer)
• HTML element and text styling (h1, h2, p, a, blockquote, etc.)
• Navigation styling
• Template styling for different page templates (home or content page templates)
• Template independent styling (specific classes that apply to all templates)

This structure allows me to keep selectors organized in a useful hierarchy, setting defaults at the top of the file, and template specific CSS below the defaults.

 Property/Value Structure

The order in which you construct the property/value pairs isn't of much significance to most developers, but it does help when working on a team. If everyone is constructing their CSS in the same manor then editing each others code will take less development time, which equals less headaches. Below is an example of how I construct my property/value pairs:

As illustrated above, I'm working from structural to presentation as I move down the list of properties. I always group my margin and padding properties with my width and height properties to allow for easy adjustments for cross-browser differences. I then move onto float/clear elements, then onto the styling of the font/text within the selector element. After font properties I begin with background and border properties. I like to leave these closer to the bottom of the list because I find that they are edited the least during initial development. The last group of "additionals" are not used as often as the others, so I like to group them below the most commonly used items. These consist of properties like: overflow, visibility, z-index, widows, white-space, etc. Unlike the pairs above them, "additionals" are only used for certain cases, where the other categories of property/value pairs are used more often.

I'm sure some people will think this is a bit overboard and anal-retentive, but when you're pumping out hundreds of lines of CSS code every day, it comes in handy. 

Everyone has their own way of doing things, different methods work for different people. Now you have an insight on how I work, tell me your methods, your ideas...

Comments Closed.

Latest Posts

• Bicycles For Sale (Mar 15, 2008 - 7:30pm)
• Alphabet Soup: Understanding Accessibility [Part I] (Feb 26, 2008 - 10:56pm)
• Do Not Call At Work List (Feb 16, 2008 - 3:02am)
• A Brief Hiatus (Feb 8, 2008 - 2:28am)
• Pneumonia Strikes (Sep 8, 2007 - 4:57pm)

About The Third Degree

The Third Degree is James Van Arsdale III's personal blog. Topics covered will range from web design and development techniques to rants about cabs hitting cyclists, and everything in-between. I encourage all to join in on the discussions, or contact me directly.