For the last few projects we’ve done at Mule, I’ve been able to work closer with the clients’ implementation teams than I sometimes do. They were building the site (or application) as I coded, which meant I got nearly instant feedback about whether or not a particular technique was going to work in their environment and could go back and change things on the fly. As a result I had to be particularly organized about how I set up my code — so I could find things quickly — and really careful about how I used classes vs IDs and how tricky I got with my code. These are just a few little observations that I made and have changed or not changed my habits accordingly.

Note: This is about writing your CSS in a text editor, not a CSS-specific editor.

I’ve always opted for a minimum number of stylesheets, versus splitting things like fonts and colors into separate stylesheets, for a couple of reasons. First, I think for the most part the combination of today’s average Internet connection speed and the average person’s browser cache settings, one large HTTP request is better than several small ones. Secondly, I don’t like jumping from document to document. I’d rather have it all right there in front of me in one big chunk (with the exception of IE-specific style overrides).

The organization of that big chunk is something I still tweak on every project: For the most part I put styles for basic HTML tags (no classes or IDs) at the very top, then the big content sections (wrappers, banner, content, footer), then break it out into sections by the name or type of template. That’s mostly for my own cognitive convenience, and it’s worked really well for me for years.

However a couple months back I saw a tip on some site (that I’ve unfortunately forgotten now, so I can’t give credit) that made a huge difference in how I work, given how laughably obvious it is in hindsight:

Alphabetize your CSS properties within your selectors.

Duh, right? In the past, I would just tack properties on to the end as I went, although I would sometimes group things in a way that made some kind of internal sense like this.

a {
    color:#ff0;
    text-decoration:none;
    display:block;
    width:100px;
    height:15px;
    padding:2px;
}

Then when I went looking for something I’d always spend time digging through lists of properties that would be in whatever order made sense at the time that I wrote them.

Now I know exactly where “height” is going to show up not only in relation to “width”, but to “color”, “position”, and “z-index”. (If I use any of the -moz or -webkit properties, they go at the end of the list.)

I was amazed and chagrined at how much sense that one practice made, but there’s a secondary effect to using it:

Keep all your properties for a given selector on one line.

I can now easily keep all my properties on one line instead of having a line-break and a tab for each property, which makes the far left column of my stylesheet a breeze to scan.

a { color:#ff0;display:block;height:15px;padding:2px;text-decoration:none;width:100px; }

Indent descendent selectors beneath their ancestors for some visual grouping.

If I have a bunch of styles specific to the footer (for example), I’ll format them like this:

#footer { ...properties... }
    #footer ul { ...properties... }
    #footer p { ...properties... }

I only ever indent one level because more than that and the indenting starts to become less efficient. This isn’t something that’s going to have complicated nesting like HTML can; it’s just a way to chunk up the stylesheet for scanability.

Code for IE6 as you go.

I’m happy to say that as a team, we at Mule are pretty darn good at designing sites that look fantastic while maintaining cross-browser consistency without getting into a bunch of stupid hacks. Sure, I’d love to say we’ve just stopped supporting or at least coddling IE6, but the sites we build have audiences that still use that browser in large numbers. Plus, most of the things that I end up having to fix for IE6 are required for its almost-as-bad sibling, IE7. So between those two, yeah, I end up having a few things that go into stylesheets loaded with conditional comments.

On one of our recent projects I decided to take the approach of “Make it right, then make it work in IE”. While that absolutely sped up the “make it right” period, the “make it work in IE” period was kind of drag because we had to go back and change some HTML that the dev team had already incorporated into their CMS. In this case it was a fairly easy fix, and it was only in one place, but if I had followed my usual rule, we wouldn’t have had to do it all.

So keep your problem children handy and if you do something in your code that you’re not sure about, check them right away.

If you have separate stylesheets for Internet Explorer, keep your selectors in the same order as the main stylesheet.

As with the alphabetizing of properities, this might seem like a no-brainer, but my habit has been to just add selectors to the bottom of the IE stylesheet(s) as I go (at least in those cases where the cascade wasn’t important). And while these stylesheets are rarely more than 10 or 15 lines, it’s more about handing things off to someone else in a way that doesn’t look like I just dumped a bunch of stuff in a box at the last minute.

These probably won’t save hours on any given project, but they will allow to think about something besides “Where the hell is that rule?” and it will definitely be easier to hand things off to the client at the end of the project.

Written by David McCreath on May 26, 2009 |