CSS: Advanced Formatting and Organization
Gone are the days of the table based layout… days where CSS, if used at all, would simply be a replacement for the notorious font tag. In this day it is very common for a stylesheet to contain many times more line of code than its corresponding XHTML document. Part of the challenge of writing good CSS is not just learning the correct properties to use, but formatting and organizing your document in a way that allows for easy maintenance and speedy display bug fixes.
Hit the reset button!
I typically start my CSS file by including the yahoo ui reset css file which does a very thorough job of clearing out of of the default stylings. This is extremely important to do so that you know that any styles affecting a given element are going to be found in your CSS document and not a bi-product of some default padding, margin, etc.
Organization of rules
I like to keep my css rules in a consistent order. My basic structure is to separate positional rules (columns and other containers that comprise the grid of page) from formatting rules (the more granular stylings). Here’s the rundown:
- Global Styles (body, lists, strong, etc)
- Headings (h1, h2, etc.)
- Text Styles
- Position/Grid layout
- Forms (which can be a mixture of layout and formatting)
- All other format rules (grouped logically and in as linear a fashion as possible)
Formatting of rules
The vast majority of stylesheets I come across when analyzing the construction of a website employ the more traditional formatting of putting each rule on one line.
h2 {
padding: 1em;
margin: 1em;
border-bottom: 0.01em solid #b2b2b2;
}
This is indeed very readable and clean, but another method for formatting your CSS rules is to put the selector, block, properties, and values all on one line.
h2 { padding: 1em; margin: 1em; border-bottom: 0.01em solid #b2b2b2; }
This keeps the actual line count of your CSS document drastically reduced and makes for easy vertical traversing of your rules. The next technique to throw into the mix is to represent the “cascading” of your rules by appropriately tabbing descendents (use 2 space tabs). This one subtle addition to your CSS document will drastically improve the speed at which a single rule can be located, regardless of the size of the document.
#Masthead { background:#3d3e38; width:100% }
#Masthead .topNav { width:57.6em }
#Masthead .topNav li a { color:#656c4a }</code></pre>
The downside to this approach is that it does take some getting used and you are trading a very tall document for one that is very wide. Personally I have no issues with long lines of code as my text editor of choice, VIM, allows me to move rapidly no matter how big or small the individual lines are.
To keep each line as consistent as possible, and to help negate the reading difficulty that single line rules introduce, I try to stick to a consistent ordering of my properties as such:
- width
- height
- padding
- margin
- float
- border
- display
- background
- font stuff (i try to keep these in their own rules, but sometimes you need to override something)
- everything else
My rationale for this is that I want everything that affects the box model to be front and center. Things that apply only to the look and feel of an element or tag are generally of lesser importance when I am hunting down some weird IE issue or what have you. I am sure many other developers could come up with reasons for ordering the properties differently, but the important take away here is just to pick an ordering scheme and get used to using it – your productivity will increase.
ID’s vs Classes – when to use what?
The simple answer to this question is: Use IDs when there is only one occurence per page. Use classes when there are one or more occurences per page.
ID’s are mainly used to identify layout structures and other strictly positional elements. Classes are used to describe an elements look and more granular characteristics that may be reused in other places within a page.
When it comes to actually using classes and IDs I prefer capitalized + camel case:
#FooBar
For classes I do something similar, but I don’t capitalize them:
.fooBar
This is fairly nit-picky, but I feel very strongly about using conventions. The important part is just to be consistent.
Flags
As pointed out in an article on stopdesign concerning css organization, flags can be a very useful way to move around a large document. Quite simply it is a method of labeling each of your rule sections with a unique identifier in a comment block. Using your text editor’s find feature, you can then jump directly to a section rather than trying to scroll or page up/down and visually locate it.
/* =HD Masthead
----------------------------------------------- */
#Masthead { background:#3d3e38; width:100% }
#Masthead .topNav { width:57.6em }
#Masthead .topNav li a { color:#656c4a }</code></pre>
A quick find on “=HD” will land you exactly where you need to be to update your sites header rules (or “Masthead” as I like to call it since “head” implies something different in HTML terms).
