Paul often tells me the CSS I write tends to look like complicated C code, and for the most part, I’d agree. The stylesheets I usually produce rely almost exclusively on descendant selectors which let me pinpoint <div>
‘s, headings, and other tags in a very precise manner for styling. In this entry I’ll talk about my theories behind XHTML and CSS code, practices I feel are better than others, and my thoughts on image replacement.
CSS Examples & Structure
Check out the Business Logs CSS file million.css
, the Gigaom.com style.css
, or the 9rules.com homepage stylesheet gameover.css
.
One thing you’ll notice off the bat is the way I organize my stylesheets — I normally group styles by what they apply to rather than where they apply it visually. For example, at the top of my stylesheets I keep all structural elements together in a catch-all titled “Body and Box-like elements” which usually holds IDs that I reserve for structural elements since they appear only once on the page. Rules like #frame
, #sidebar
, and #footer
will go here. Under those are all my heading styles (H1-H6), then all paragraph styles, then link styles, lists (including navigation), and so on. Compare this to how my friend Dan writes his style sheets; he normally groups styles by where the style is going (top section styles, sidebar styles, content styles, footer styles) rather than the type of style it is. Neither style of coding is “the right way”, they’re just two different ways of looking at a site’s design and structure. I personally think that the reason I write mine that way is because of all my experience with real programming (Java, C, PHP, Perl) so my way of organizing CSS files just seems more logical in my brain. Who knows.
I’ve been writing CSS commercially now for a shade under three years, and once you have a few thousand lines of CSS under your belt you tend to develop patterns that make it easier and faster to get work done. One of the patterns that I use that helps me immensely is the indentation of CSS rules based on their parent/child relationship. Here’s an example from the 9rules CSS:
#frontpageads ul {
display: block;
margin: 24px 0 16px 0;
_margin-top: 12px; /* Double margin bug, IE6 */
padding: 0;
list-style: none; }
#frontpageads ul li {
height: 75px;
margin: 0 16px 8px 8px;
padding: 0; }
#frontpageads ul li a {
border: 0 !important; }
See the pattern? The #frontpageads ul
rule is the parent and start of the unordered list style, then the child element is the #frontpageads ul li
which is next (indented one level), and then the #frontpageads ul li a
style is last which is the child of the list item. The indenting of child rules helps set up a visual hierarchy which is really handy when you’re dealing with 1000-line CSS files since they can get unruly pretty quickly. On a normal site, I might have numerous navigation or list styles: one for the top navigation, one for a secondary nav, a sidebar list (say, categories on a weblog), and then a normal list style for content. That’s four different unordered list styles, all with the same ul
-› li
-› a
code progression needed to style all parts of the list. The indenting is really handy because I can identify each list style block visually without having to look closer at the name of the rule. This helps me jump directly to a code block without having to waste time to see where one block starts and another begins.
Make Your XHTML Lean
The very first thing I do after I have the visual design of a page mocked up (in Photoshop, OmniGraffle, etc.) is jump into the XHTML. I have the visual design open in one part of the screen, and TextMate open in another so I can look at the design while I write the most semantic XHTML I can muster. I always write the XHTML/CSS for my own designs because I can just look at it and see the XHTML/CSS in my head. I can see how the structure will be laid out, which areas will be blocked off, how navigation will be coded, etc. A few weeks back my girlfriend said that in the middle of the night I was talking in my sleep, saying things like “H5 and H6!” after a long day of CSS coding, I mean how lame can ya get 🙂
One of the hallmarks of CSS-based design, to me, is the separation of design from content. In my HTML files you will never, ever find an <image>
tag that links to something that is used for the design of the page rather than the actual content. Images that build the design structure of the page are meant to be contained in the CSS file as background-images
, not as images
in the HTML itself. If you keep all the design in the CSS file and all the structural markup and content in the HTML, the project will be much better off and Jeffrey Zeldman will smile down upon you.
In order to have background-images
as design elements in your CSS, you’ll probably need to use some form of image replacement. Image replacement, for those who aren’t accustomed to the term, is the method that moves the text that would normally show up in an element’s display out of the way so that element’s background-image
can show through. The advantage is that you can use regular HTML tags like H1
to give semantic meaning to things like logos, where before you would just drop an HTML image
tag in there and call it a day. By still using the H1 for the logo, you are giving meaning to the ordinarily meaningless image, and you can keep all the design in the CSS and not muddy up your HTML with image tags.
A few years ago I wrote about the technique I used for image replacement by way of a negative text-indent (which instead of indenting it to the right, it indents it way off screen so it’s not visible any more.) This technique is the one I use every single day, and I’ll go ahead and recommend it to newer CSS coders because it’s very simple to implement and doesn’t require extraneous HTML tags to function. I won’t get into the details of it here, but if you jump over to the 9rules CSS or Om’s CSS, and do a find for “text-indent” you can check out the code in action. Many other designers use this technique as well (Doug Bowman rocks it) so it’s not just me saying this because I’m biased 🙂
Round Up
These are just a few of the CSS tips I have, and I’m sure our readers have a bunch more, so feel free to share them.