CSS Mess

To say that cascading style sheets (CSS) have become indispensable to my daily activities as a web designer would be a gross understatement. So gross, in fact, that it’s absolutely ludicrous to suggest anything else. There are some out there who insist on remaining in the dark ages, but the simple fact is that CSS, in conjunction with well-formed, valid, and semantic (X)HTML, is slowly and surely becoming the de facto standard for putting together web pages.

That’s exactly the way it should be, and it’s only going to get better. It’s just sad that it’s taken us this long to get to this point.

The separation of a website’s content from the way it is presented — a concept that is at the very heart of CSS — is a very beautiful thing. However, it’s recently been impressed on me that it’s also a double-edged sword. On the one hand, the ability to quickly make site-wide design changes by simply modifying one CSS file is just too great. It makes site implementations, updates, redesigns, and modifications easy as pie. It allows us web designers to focus our time and energy on more important things, rather than waste them on worrying about nested tables, spacer GIFs, and other bits and pieces of “tag soup”.

But on the other hand, CSS can make implementations, updates, redesigns, and modifications too easy for our own good.

Recently, I’ve been working on several projects (both at work and in my spare time) where I found myself making constant tweaks to the design via CSS, for various reasons (client requests, my own anal-retentiveness, etc.).

At first, it was pretty minor stuff: changing the background color of a DIV, adding some extra space around a paragraph, changing the border color of an image, shifting a menu over a couple of pixels, etc. But it’s a slippery slope, and before I knew it, I had made so many changes that I just lost track of what was what.

My CSS had become much more complex, as had my markup, with extra DIVs, IDs, and classes floating about. I lost track of whether a particular tag was actually being used, or if it had been part of an earlier tweak that I had since decided against. And it was the same with my CSS rules. Essentially, I had allowed all of the additional complexity created by my various tweaks to offset the benefits of using CSS and good (X)HTML in the first place.

Unfortunately, it’s too late in the process of these particular projects to simply re-code the layouts from the ground up, either because of deadlines or because doing so would take time from other, equally-pressing projects. But it is definitely something to be aware of, especially once the design is fairly close to completion and you find yourself battling the urge to go in and tweak things even more.

But it’s not just in existing or nearly-completed projects where I need to be mindful of these things. The easy-to-abuse nature of CSS is also something I need to keep in mind during the initial stages of a new project.

I do the bulk of my design work in Photoshop (others might use Fireworks or Illustrator). But oftentime, I find myself doing only a cursory amount of work in Photoshop. I create the very minimum of graphics that I’ll need, slice them up, and save them out. Then I go about doing the bulk of my layout in good ol’ BBEdit, using CSS to push things around and lay them out.

Obviously, this approach has some real benefits. No longer do I have go back to Photoshop, make changes to my PSD file, and re-save the graphics every time I want to change something. Now, with a few keystrokes, I can reposition elements in my layout, do rapid mockups, and quickly test layout ideas without having to commit too much time and effort.

But again, there’s a slippery slope here. As tempting as it is to do the bulk of my layout the BBEdit, I often find myself pushing ahead with the HTML and CSS before I have a clear idea of the end result. I give into that urge to roll up my sleeves and just start rooting around in the code, as there’s something quite gratifying about coding a website from the ground up, hitting “Refresh”, and instantly seeing the fruits of my labor.

Obviously, any artistic process — and yes, I do consider web design to be “artistic” — involves some measure of finding and solidifying the design as you work on it. Not everything is immediately evident; you have to allow room for “happy mistakes”. However, web designers have to balance two things as we work on designs; getting the visual aesthetics right while also making sure that the underlying (X)HTML and CSS remains as clean and efficient as possible.

When I simply plunge headfirst into my code without having solidified the design to some extent, it’s easy to end up with code that is needlessly complex and nonsensical. And as a result, I often have to re-code the now-realized design to fix all of the coding errors introduced as I fumbled about, trying to “discover” my design.

At the risk of sounding heretical, this is not a problem I remember having very often back in the days when tables were the only option for doing layout. Because tables are pretty inflexible, you had to fully flesh out your design before you could commit to coding it. You had to have a pretty good idea of where every background, button, and other graphical element was going to go before you fired up your HTML editor, because making even minor changes later would take so much more time and energy (not to mention swearing and hair-pulling).

Obviously, I’m not recommending that folks should ditch CSS and go back to the dark side. Rather, what I’m saying is that CSS is a very powerful thing, and as a result, it’s easy to either abuse that power (by constantly tweaking a design to within an inch of its life) or get caught up in the use of it and design recklessly (by firing up your HTML editor prematurely).

These recent projects have reminded me of just how important it is to have a solid concept in mind — and onscreen — before proceeding further. You don’t want to lose control or get ahead of yourself. Once you have that solid concept and have signed off on it (figuratively and/or literally), then you can do all of the coding and tweaking you want because you have a standard against which you can measure your efforts.

Furthermore, it’s important to make sure that your final CSS and (X)HTML is as efficient as possible. That way, should you have to return to the design in the future to make some updates, less time can be spent trying to figure out what this or that rule or element does, and more time can be spent on actually getting the work done. And it’s equally important to make sure that any of the updates that you do make don’t needlessly undermine your code’s efficiency, ensuring that future updates are as easy and painless as possible too.

I know this all sounds like common sense, but when working with something as flexible, liberating, and downright cool as CSS, it’s all too easy for common sense to fly out the window. Certainly, there will be times when a design does get away from you, either due to a client’s requests, or because of a shift in project scope and goals, or some other thing that is out of your control.

But even then, having a clearcut concept still gives you a foundation so that you’re not just flailing around in your design, or beginning your work without any real map or plan.

All of these are ideas and thoughts that, to be completely honest, I’ve lost sight of to some extent. Either I become sloppy when working on existing designs, or I get excited and plunge headfirst into coding a design before I really know just what the heck I’m doing. As a result, I find myself locked in drudgery, and my work simply isn’t as rewarding or enjoyable as I know it can and should be.