WEB Advent 2009 / CSS and Other People

The road between design and development is fraught with all sorts of peril — as Helgi has already pointed out. Bringing a visual concept to the Web is a group effort that often requires the collaboration of people with different backgrounds and areas of knowledge.

From a developer’s perspective, “design work” means having to deal with the often hated, sometimes impossible, and always challenging task of translating a designer’s comp into a combination of HTML and CSS that will render properly on browsers that are often at complete odds with one another.

This process is a bit like a wicked game of chess; there are only a small number of fast and set rules, but an almost unlimited numbers of ways (both good and bad) to achieve a goal. Like a game of chess, a player who doesn’t understand the rules can end up in serious trouble, which, in the case of front-end development, can easily roll downhill and affect other people on a project.

I have seen (and experienced) this problem tackled in a number of different ways by different teams; while there’s probably no right solution, here’s how we do it.

Establishing a good process

Front-end development needs to be a collaborative effort from the very beginning. A designer who builds comps blindly, without any input from the people who will have to translate the design into code, is asking for trouble. This can be easily compounded by showing the client a concept only to have to go back to them to let them know that it can’t be done in a way that will look good in a browser.

The first step in producing a design, therefore, needs to be a contract between the designer and the developer aimed at establishing whether the former’s ideas can actually be translated into working code. Typically, this is what a wireframe is for. (Personally, I’m not too keen on showing wireframes to customers, unless they have a high degree of familiarity with web design, because you will otherwise, invariably, have to explain why they are paying your firm to draw a bunch of boxes.)

The interaction between design and development shouldn’t end here, however — I would, in fact, argue that a developer should be allowed to review every comp before it is sent to the customer. This makes it possible to catch design decisions that are very difficult to implement in practice — such as gradients anchored to the bottom of a columnar <div> that needs to expand vertically — before the client becomes too attached to the idea.

As a side note, comps should include more than just the visual look of the page template. For example, the designer should create a specimen of all the styles that apply to the design: headings, paragraphs, lists, and so forth. Naturally, the complexity (and completeness) of the specimen should be proportional to the complexity of the web site; an online brochure is unlikely to have the same requirements as, say, an online encyclopedia.

CSS from the inside out

Once a design has been agreed upon, approved by the customer, and sliced to perfection, the process of transforming the comp into a series of files has three primary goals:

  1. Minimize the use of images
  2. Maximize browser compatibility
  3. Minimize code complexity

The reason I like to minimize the use of images in a design is that it makes managing changes much simpler. Making changes in code requires fewer steps and produces more immediate results, leaving more room for experimentation in the implementation phase. This is particularly true with backgrounds (my least favorite design element), which clients seem to particularly enjoy changing. Naturally, minimizing image usage shouldn’t come at the expense of either maintaining good browser compatibility or writing code that is easy to maintain.

Producing good CSS is also a multi-step process that goes from the generic to the specific:

  1. Start with a reset template (such as Yahoo’s) to ensure that your code will be based on a common starting point across multiple browsers.
  2. Define a grid for your site using either one of the several pre-packaged frameworks — such as the 960 grid system, baseline, or YUI’s — or your own layout, based on your specific needs.
  3. Compile a generic stylesheet of all relevant elements that are common throughout your templates: text, tables, lists, forms, and so on.
  4. Finally, write CSS for each page

This approach allows you to progressively override your styles from the generic to the specific so that your templates will present a common visual identity unless you need otherwise.

Pick your poison

No matter how careful you are, your design will break on some browser. If you’re lucky, it’s a browser that you don’t need to support, but most likely, you will at some point need to make a compromise between your desire to perform a task and the browser’s ability to make that task possible.

The line between acceptable and unacceptable in this particular case varies, and depends on the lengths to which you are willing to go in order to make your design work.

When it comes to cross-browser compatibility, you typically have three options:

  1. JavaScript
  2. Browser hacks
  3. Graceful degradation

A little bit of JavaScript — in conjunction with a good framework — can go a long way toward making a design work without driving you insane. Purists will likely spurn this option, but I don’t have much time for purism; over 99% of users have JavaScript enabled, and as long as its use only affects the visual layout, I don’t mind using it. (Using JavaScript to provide critical functionality, on the other hand, is something that should be avoided.)

Browser hacks, which take advantage of quirks in the way a particular browser deals with CSS syntax in a different way from the others, are by far my least favorite method of coaxing a particular browser into behaving. They work by combating brokenness with more brokenness, so to speak, and I don’t think that relying on bugs is a good way to develop software of any kind.

My preference is to instead rely on graceful degradation; allow your design to degrade without compromising its overall integrity. A typical example where this approach could work is round corners, which can easily be produced on Firefox and Safari using pure CSS, but require an ugly hack in Internet Explorer.


Testing design is a painful process. On a typical project, each template will have to be tested on at least three — and maybe as many as six — different browsers. This requires a lot of time, and a practically unlimited amount of patience.

There are some tools that will help in the process. Certain web sites like Browsershots, for example, allow you to see how your design renders on a variety of browsers and platforms, while Microsoft’s Expression now includes a feature called Superpreview, which, among other things, allows you to perform side-by-side comparisons between any version of IE (including those you don’t have installed on your computer) and Firefox. Sadly, it’s a Windows-only product and it doesn’t yet support Safari.

At the end of the day, front-end development is a collaborative effort, which means that you can always let someone else do the testing!

Other posts