I'm not going to go into detail about the benefits of using CSS, which have been covered so many times before. In short, it provides a convenient way to separate presentation logic from actual web markup, it reduces duplication of style-related code, and best of all it's incredibly flexible! Ah, but that flexibility is a bit of a double-edged sword: allowing many ways to do the same thing means similar things will likely be done differently in different places, gradually leading to a mess of files which is a nightmare to maintain.

If you don't believe me, install a tool like FireBug and pull up a favourite large-scale web site. Set a small goal for yourself, like changing the colour of an entire page's background, or changing the bottom margin of all headings across all pages, something that should ideally only be a few lines to fix. Is it really as easy as it sounds? The answer is likely no, and there are many factors that can contribute to this:

• Multiple developers working on separate areas of the site, each using their own set of rules for how their CSS should be written.
• Years of modifications by different (or even the same!) developers are done with little consistency across the site.
• The original developers saw CSS as an afterthought; something you work on after the site "works" that can be done in any number of ad-hoc ways.
• The CSS was generated using a WYSIWYG-style editor (such tools are notoriosly bad for producing maintainable code).
• The original CSS is out of touch. The web changes quickly, and even sites that are only a few years old may be using syntax that has been updated or replaced.

Even well-meaning developers will make mistakes while modifying files that were started by others. If the existing file already does the same thing in several ways, which way should one use? What if the particular file only defines one way of doing it, but other files use a different method? What if the existing way is consistent, but far from optimal? Refactoring one CSS file (let alone several) is a remarkably grueling and time-consuming task. Is this unavoidable? No! It just requires a little planning and a little discipline.

The trick is to set up (and subsequently follow!) some design guidelines to make sure everyone starts, and most importantly stays, on the same page. This is best done at the beginning of a project, but it's never too late to start doing something right. For example, here are some things you may want to set guidelines for:

• How specific should selectors be? Is it all right to define a general rule for all instances of <div>, or should each <div> require a class? Should selectors be classes-only, or are ids allowed as well?
• Should traversing the DOM, as in "div.classA span.classB a" be allowed? encouraged? mandatory whenever possible?
• What sort of things are forbidden? This is important to consider for things like wildcards (*), inline-styles and <style> tags, etc.
• How should CSS be broken into multiple files? Does each section of the site get its own file (login.css, register.css, menu.css...) or are files broken up by functionality (layout.css, form.css, graphics.css...)?
• What level of CSS quality are you looking for? Does all CSS have to validate? What about browser-specific rules that are likely non-standard? (IE's conditional comments can work wonders here)

There is no right or wrong answer to any of those questions. What's important is to give each option some thought, and decide which is best for your particular needs. These are design decisions that involve real trade-offs in maintainability, functionality and resource needs, and just like any other design decisions, they will have a real impact on the outcome of the site. Deciding upon and following through on just a few well-defined guidelines makes these factors clear, and provides an optimal environment for developers to write maintainable code.

Labels: CSS, web development