Got Messy CSS? You're not Alone

Woolly, the CSS sheep. You just got a new web design gig. There’s a blank CSS file staring out from your favorite text editor. This time, you tell yourself, it’s going to be clean and simple CSS. No crazy descendant selector spaghetti code, no resorting to inline styles for quick changes, no !important. Clean, simple […]

Woolly, the CSS sheep.

You just got a new web design gig. There's a blank CSS file staring out from your favorite text editor. This time, you tell yourself, it's going to be clean and simple CSS. No crazy descendant selector spaghetti code, no resorting to inline styles for quick changes, no !important. Clean, simple CSS built on established best practices.

Three months later you're trying to figure out why the new #sidebar .row h3.smallHeader rule is going to affect the existing #sidebar .row header h3. You've failed. Again. But it's okay, and you're not alone.

In fact, CSS guru Nicole Sullivan thinks the reason you've ended up where you are again might even be because of "best practices."

Sullivan is perhaps best known for having wrangled the massive and tangled CSS of huge, complex sites like Facebook into something even mortals can understand. In a talk at this year's Webstock conference Sullivan calls out some so-called best practices of CSS that might in fact be part of the reason we end up with tangled CSS:

It is time to let ourselves off the hook. There is nothing we could have done by trying harder. There is no magic juju that some other developer has that we don't. Following our beloved best practices leads to bad outcomes every. single. time.

What are those flawed best practices?

  • Classitis!
  • Never add an non-semantic element
  • Or, a non-semantic class
  • Use descendant selectors exclusively
  • Sites need to look exactly the same in every browser

No doubt some of Sullivan's arguments will be controversial with Webmonkey readers, but she has a point: we have best practices, but we still end up with messy, difficult to maintain stylesheets -- clearly something in those established practices is not working.

It's important to note that Sullivan isn't suggesting throwing out these ideas, just that developers ought to see them less as rules and more as suggestions. For example, don't litter your markup with classes if you don't need them, but when you do, don't feel like adding a non-semantic class is the end of the world.

If you'd like to hear the entire talk, head over to the Webstock site for a video and some slides.

See Also: