CSS: Just Try and Do a Good Job

Avatar of Chris Coyier
Chris Coyier on (Updated on )

DigitalOcean provides cloud products for every stage of your journey. Get started with $200 in free credit!

Have you ever worried that you’re approaching CSS all wrong? That you’re missing out on some new approach that makes everything easier and better? That you wish you were more confident about the state of your CSS?

I’m sure we can all empathize with Anna’s sentiment here:

I worry about you if you work with CSS a lot and have never felt that. You’re either scary smart or, you know.

Here’s how I’m trying to approach CSS these days: just try and do a good job. I don’t subscribe to any specific methodologies or strict rules. More like a set of loose guidelines that attempt to keep things under control, held together by the idea that I’m actively trying to do a good job.

Caveat: this is just me. I mostly work on projects where it’s mostly me touching the CSS. That applies also to 55% of you, accordinging the most recent poll running here. I’d speculate that the more people you work with, the more benefit you get to stricter rules than I adhere to.

Here’s a little elaboration on “just try and do a good job”:

Don’t be lazy. You know when you’re being lazy about something. By which I mean you slapping in a quick fix for something rather than trying to understand the problem. Or dropping some CSS into whatever file seems convenient at the moment rather than thinking about where it best belongs. Or you are avoiding creating a new pattern when it seems clear that’s what the situation calls for. Or continuing to use a pattern that is biting you. Sleep on it. Don’t rush. Do it up right.

Do things how you would do them. You know what? I like light usage of child selectors in modules. .module > h2 clicks with me a lot of times. Certain strict methodologies would disagree. I don’t really care. I’m going to keep doing it until it actually causes some negative consequence, which it hasn’t yet. If it does, I’ll change, because see above.

Name things how you would name them. If I let a methodology tell me how to name things, I know me, my mind starts staging a coup. I might play along for a day or two until I abort the methodology and take full control again. On projects entirely build from my WWINTT (What Would I Name This Thing?) strategy, I feel most comfortable and efficient.

Use tools that are clearly useful to you. I’m not even going to name any tools because that’s not what this is about. If I can identify a tool that has clear benefits to me, I’ll use it. It could save time, produce better output, allow for better organization, solve a performance issue, automate a best practice, whatever. I’m in.

The one “rule”ish thing thing I really believe in: keep your selector specificities fairly low and flat across your whole project. Harry’s specificity graph is a nice way to think about this. Specificity will trend upward, so never start high, as the ceiling can easily become problematic. Mostly: .class {}.

Revisit sections of your site on purpose. Probably not just because you want to clean up the CSS there, but because you want to make that section of your site better in some way, for everyone. I find that every time I revisit an area, it’s an opportunity to clean up all the code that touches it. That helps me feel connected to and less afraid of old code.