A common problem that web apps face over time is CSS bloat. Especially with new sites, any rapidly-evolving app is going to be subject to some serious front-end abuse in today’s extreme programming world. As features are added, removed, and modified on a whim, it’s all too easy for CSS to get out of control.
This is something we’re currently faced with at Zenbe, and my current task has been to refactor our app’s CSS by finding and eliminating a decent amount of bloat that’s developed during our app’s first year (well, 8 months).
When starting this task, I knew that we’d have to come up with an at-a-glance method for our developers to take the newly re-factored CSS and run with it. A lot of the CSS bloat that I initially saw was related to a simple lack of consistency as new UI items have been added to our system. Take our buttons, for instance – we started off with one-size buttons, then we had 2, then we added different colors, and so on. As these items have been added, instead of letting the CSS classes build off each other*, we’ve acted like they’re not related at all – and before we knew it we had a ton of redundant CSS.
This is where test-driven CSS comes in.