zahnster

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.

Lining up UI items is a quick and easy way to build off consistencies while avoiding inconsistencies.

Now, I’m not 100% sure calling this method of testing CSS “test-driven” is accurate, as you can’t really have tests for things with no true variables. Rather, the test-driven CSS I’ve created is almost like a UI element showcase. It gives us a one-stop shop for seeing our different UI items (buttons, form elements, glyphs, dialogs, etc) in their pure form – and to enable us to build new features based off what’s existing.

We gain some critical things by having this testing in place. First, we have a singular place where we can see all of Zenbe’s UI items in their pure form – all lined up in a row. It’s all to easy to mis-slice something by 1-2 pixels and never notice in production – it’s quite a different story when they’re all lined up next to each other. I was able to reduce nearly half of the code in our buttons.css file just by aligning the button slices so they were the same dimensions – turning any variations of these buttons into a simple background-image replacement, instead of replacing the image and resetting dimensions, padding, and margins.

Additionally, as we make changes to our code, it gives us a nice testing place so we can make sure that all of the site’s UI elements still render the way they should, which is why I’m inclined to call this ‘test-driven’. Additionally, the UI items are created in a tdd-like fashion: first the HTML is created, which will ‘fail’ without the proper CSS. Then, the CSS is written so that the HTML element renders as it should.

As this continues to be built out I might face some unseen obstacles, but so far our pseudo test-driven CSS is going to be a huge help in keeping our CSS code mean and lean.

^{*This concept will be covered more in an upcoming post about CSS inheritance tips}