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}

But what do you do when your product is a complex web application? How do you best maintain your stylesheets when your app is constantly growing and evolving? It’s a lot more challenging than you might think, but there are several things you can do to keep your code optimized and maintainable.

In order to organize my thoughts, and perhaps throw some inspiration on the subject, I’m starting a series of posts each featuring a different thing you can do to best optimize and organize your css to face the challenges of a frequently evolving web application.

The first thing I’m going to talk about is the importance of an asset packager. It may not seem critical, but it really is, as it empowers you to create maintainable css documents.

For those who aren’t familiar, asset packagers allow you to combine different stylesheets into one big, compressed stylesheet. On smaller apps, it’s very common to include the entire site’s css into one file (or a very small number of files). This is good practice – performance rules state that you should minimize http requests. However, with a complex app, forcing all of your styles into one sheet can be a quick road to disaster. Once your css is above a certain number of lines (500+ in my eyes), it can become very verbose, unorganized, and difficult to maintain.

For bigger apps, it’s very helpful to piece apart your style rules into different files based on functionality. For instance, with Zenbe, we have many (many!) different stylesheets – we’ll have one for base styles and one for the different buttons we have. We’re not afraid to break up our css in the smallest chunks possible, because it helps our files have meaning. If there’s a style problem with a button, I know it’s in buttons.css. I don’t have to dig around for it in some obscure, 10,000+ line global stylesheet.

When you make the choice to break apart you css into small, manageable chunks, you’re breaking the optimization rule of minimizing http requests. Even if you use @import, each fetched stylesheet still requires an http request. So, this is bad, right?

Not at all, because this is where asset packages come in.

Originally built for Rails by Scott Becker, the asset packager we use for Zenbe actually compresses all of our different stylesheets into one file. It does this on the server level, so you can easily combine any number of stylesheets while only having one http request on the client level. An added benefit of the asset packager is it also strips all extra spacing, so you can use the ‘1 line per style’ css code style without feeling guilty about whitespace and file size.

Asset packager isn’t just for rails, either. There’s a PHP version out there as well, which was inspired by the one Becker wrote. If you use a different language – check around for one in whatever you program in. It’s definitely worth it.

So that’s basically it for asset packages. I can’t express how important it is to use some form of this on any complex applications – nothing kills app development like trying to keep some global stylesheet organized and maintained on a complex app that’s under constant revision.

It’s one of the more common ‘css design faux pas’ that I have encountered as a web developer, and to me just demonstrates a lack of understanding about how box model elements behave. 99% of the time heights should be left inherit – locking yourself into a height can quickly bring limitations to your site layout, provide a maintenance nightmare, and they’re almost never needed.

By default, an element will be as tall as the elements/content that are inside it. A few cases which might cause a container’s height to collapse are if your internal elements are floated, or if they are absolutely positioned. In both of these cases, the easy answer is to set a height on the collapsed element and forget about it. However, this isn’t really good practice, and you’re basically treating the symptoms and not the cause.

If you’re losing height because of floated elements – clear them, either by using an overflow property on the containing element or doing a good ol’ fashioned clear div.

Absolutely positioned elements can be a bit trickier, since the whole point of them is to not have layout space, so heights are acceptable, however I like to use padding whenever I can, just to avoid being locked into a set height.

Hopefully these tricks will be useful to someone, and make CSSing a bit more flexible and fun.

Not too long ago a new trick came along which had many css developers feeling lighthearted – a way to clear floats without markup. It was a simple, reliable css method that’s been around for ages – the overflow property. Simply by declaring this (usually to auto or hidden), you are able to extend the parent div over the floated divs, and effectively clear your divs – something you have previously needed an empty block level html element to accomplish.

I am afraid, however, that this trick is too good to be true. While it may work well on simpler projects, the method becomes inherently buggy whenever mixed with or around JavaScript, specifically in the Safari web browser. Additionally, it fails to clear certain divs in IE6.

So, when it comes to clearing floats – I’d say stick to the markup method. At least until a real solution comes along.

There’s a new trend going on, one which I am sure comes from the many text-replacement css methods that have been popping up in every css book published: entire pages with absolutely no imagery. Now, I know css is all about separation of content from presentation, and that css images are easier to replace than html images… you can chat me up about it all day. Fact remains that sometimes images say more about the content than they do the presentation.

Case in point: logos. I’m sure clients will not be thrilled to know that their website prints without their company logo being displayed. That instead of their brand, you get some shoddy Times New Roman font (which is probably wrapped in some ugly link style). I don’t blame you for wanting to take the graphic out, I’ve been guilty of it many times in the past, but I’m seeing this trend more and more and it really should stop. Logos aren’t presentational – they are pure content and represent the company visually.

It’s not just logos, either. I’ve even see sites inserting story images with css, calling it through a div with the image caption. There’s a time and a place for css, but that’s not it, because part of being a true css expert is knowing when to use it, and when not to.

However, there’s one thing that I have never been able to get around without filters, and that’s font-sizes.

Font sizes can be called in three ways – using pixels, ems, or percentages. Setting your font-size in pixels is optimally ideal (although I could get into many fights with some of my college teachers about this) – we’re web developers, we live in pixels. We’re familiar with them, and we know how big a 10px font looks on the screen. Besides, ems and percentages are too relative to the browsers – 1em in Firefox is not the same as 1em in Safari.

So why not just use pixels? Well, technically you can, and it works cross-browser, cross-platform. However, there’s a catch – if you set a font size to a pixel amount in IE – it’s stuck at that size for life. Even if you adjust the font size in your browser settings. It’s a total accessibility crutch for close to 80% of the web viewing market.

So, if we want to develop accessible websites, what do we do? In college, I was taught to use ems, and it was all very defended: they’re fonts, after all. Set your font and get over the minor inconsistencies. It might have worked in Advanced Web, but in the Industry you have clients and designers breathing down your neck – they don’t understand why the font is slightly bigger in Safari, and they don’t like it.

So what do we do? The only real solution is in IE filters – sometimes they’re just a necessary evil. Luckily, the font-size problem is only in IE6 and below, so one simple star filter can allow you to set browser font-size in pixels, but in IE, use ems.

html { font-size: 10px; }
* html { font-size: .8em; }

For the rest of your font adjustments, feel free to use percentages or ems – everything will be relative to that base font-size setting.