SXSW2012: CSS for Grown Ups: Maturing Best Practices

In the early days of CSS the web industry cut its teeth on blogs and small personal sites. Much of the methodology still considered best-practise today originated from the experiences of developers working alone, often on a single small style sheet, with few of the constraints that come from working with large distributed teams on large continually changing web projects.

The mechanics of CSS are relatively simple. But creating large maintainable systems with it is still an unsolved problem. For larger sites, CSS is a difficult and complex component of the codebase to manage and maintain. It’s difficult to document patterns, and it’s difficult for developers unfamiliar with the code to contribute safely.

How can we do better? What are the CSS best practises that are letting us down and that we must shake off? How can we take a more precise, structured, engineering-driven approach to writing CSS to keep it bug-free, performant, and most importantly, maintainable?

Andy Hume, The Guardian

CSS for grumpy old people

Why best practices are killing us.

  • Piggybacked on web standards
  • Breaking away from Cruft
  • Separation of content and presentation
  • CSS Zen Garden - showcased the power of CSS
  • Solidified the idea of content and presentation
  • Opened a bit of a trap door that we shouldn’t add styling hooks to a document
  • Not thinking about what it mean to write flexible CSS
  • Web standards obsession! Obsessed with removing any presentational markup from the content
  • Problematic in the real world
  • CSS becomes completely reliant on the document never changing
  • IDs and Class Names allow your code to become more readable
  • Simple is a really good thing!
  • We are terrible at managing complexity - the complexity of the css of a large site
  • We have too much flexibility and power. Not enough constrains.
  • We need to build components and forget about it. Other parts of the code base shouldn’t interfere with it. Small pieces loosely joined.
  • As people putting code together we need to build our own constraints into the system.
  • Quality code? Optimized for change. How easy is it to make changes to code?
  • Not optimized for change? Harder to add features, fix bugs, etc.
  • 261 declarations of blue in Facebook css (
  • Sass, LESS, Stylus (worth looking at to see if they will fit in your workflow)
  • More interested in projects like: OOCSS, SMACSS, CSS Lint

Layers of CSS

  • HTML Document -> Base Styles (font styles, line height, link colors) -> Modules (indiv. larger components) -> Layout Styles (page layouts)
  • How they contribute and (don’t) interact with each other

What’s so bad about this?

.green { color: green; }

When it changes to this:

.green { color: red; }

Document and module needs to be loosely coupled.

Come up with your own naming conventions.

  • .h1
  • .h2
  • .h3
  • etc

Or, even better…

  • .h-headline
  • .h-subheads

Don’t dismiss because of dogma. What you gain in tidier mark up you lose in simplicity.

What’s actually different about a module when it’s in the sidebar?

  • Color? Then use…
  • CSS Double Hyphen?

Media Queries

  • Module needs to know if it has enough room. Responsive to its local context.
  • Can’t do it in CSS! Can do it in JS.
  • Selector Queries

Presentation Class Names as part of Base Stylesheet

  • .margin-top
  • .margin-bottom
  • Module Content
  • .gutter-left
  • .gutter-right
  • Added non-semantic class names and additional divs
  • Sprites = can be a standalone thing using an Element. Twitter bootstrap uses this.

Docs and Styleguides

  • The way we package code makes such a big difference to quality and consistency
  • Document (styleguides) in code, not PDF, PSD, PNG, InDesign, etc
  • Good examples: Twitter Bootstrap, Paul Robert Lloyd (styleguide)
  • Module Library
  • Stay away from the concept of the page as long as you can

Progressive enhancement - approach design from a base design.

Question: How do you apply this to a CMS?


⇠ Next Article Previous Article ⇢

About The Author

G. Brad Hopkins's avatar
  • G. Brad Hopkins
  • About Me: I bought my first computer - an Apple Performa 6320 - when I was in college and have been building websites ever since. These days I spend most of my time writing code and helping to bring interesting projects to life.
  • @gbradhopkins