One of the big advantages of using CSS is that it saves you time and effort by pulling repetitious formatting code out of the HTML markup and consolidating it in the CSS style sheet. You can reuse styles to format multiple text blocks and to control layout and formatting on multiple pages. And, having reusable formatting in a centralized location saves development time—especially when you need to edit or update the Web site.
In contrast, one of the problems of working with CSS is that the CSS file can quickly become a confusing mess as you add more styles to the style sheet. There are styles to redefine HTML tag attributes, class and id selectors to format various text blocks, and still more styles for page layout. Some styles are sitewide, while others are applicable to individual pages. Then, there are all the hacks that are required to deal with cross-browser compatibility issues. With all that stuff going into the style sheet, it's easy to see how things can get out of hand if you don't have a coherent plan for managing your CSS style sheets.
The problem of the ad hoc style sheet
Most Web builders start working with CSS the same way: They create and edit styles as needed to format whatever portion of the Web page they're working on at the moment. Initially, the styles reside in the document header, but they get moved to an external style sheet when the contents of the <style> tag grow too big or the Web builder wants to use the styles in another document.
This ad hoc approach to style sheet development usually results in all the styles being stored in one CSS file with no particular order or organization. As the style sheet grows in size, it becomes harder to find and edit the styles you need. What's worse is that it becomes almost impossible to trace inherited properties through the cascading styles. You might get by with ad hoc style sheets for a single Web page or a small site, but the challenges of working with a big, disorganized CSS file grow exponentially as your sites get bigger and more sophisticated.
Have a plan
"Plan your dive; dive your plan" is a saying that SCUBA divers use as a reminder to work out a plan in advance and then stick to it. It's essential for divers to carefully plan depth and bottom time in order to avoid potentially fatal problems such as the bends. The consequences aren't as dire for Web builders, but if you want to avoid a lot of frustration and wasted time, then it's important for you to have a plan for managing your CSS style sheets.
There are different strategies for CSS style management. You may need to try variations on several approaches before you find what works best for you. The important thing is to avoid the chaos of an ad hoc style sheet by planning your CSS style development for a given site, and then following that plan.
Organizing your CSS styles
A common mistake that many Web builders who are new to CSS make is to put all the styles for the entire site into one CSS file. That approach works only for very small sites with few (if any) page-specific styles. For all but the smallest sites, it usually works better to use multiple CSS files.
For example, you might have one CSS file devoted to sitewide styles and separate CSS files for identifiable subsets of site pages (such as pages for a specific department or pages with a different layout style). For styles that are unique to a specific page, use a separate CSS file for each page (if there are too many styles to fit comfortably in the document header). You link or import the appropriate CSS files for each page, so that you load all the styles needed to display that page, but very few unnecessary styles that only appear on other pages.
A technique that I like to use to organize CSS style sheets is to divide the style sheet file into sections. For example, in the main style sheet, the first section contains the styles with the broadest sitewide application, so it's mostly populated with styles that redefine the properties of HTML tags. Another section contains styles to format common page elements, such as the navigation bar or footer. The styles that control sitewide page layout go in another section. Subsequent sections create groupings of styles with a progressively more specific focus.
For a typical site, all the sitewide styles can go into one CSS file, with comments to delineate the sections. For a more complex site, you might want to break each section out into a separate file. A lot of Web builders like to separate the styles for page layout from the styles for formatting text and other elements by putting them in different CSS files.
Take advantage of the cascade
One of the defining characteristics of CSS is the cascade, which is what enables subsequent styles to inherit most of the properties of a previous style. That means that each style needs only to define the noninheritable properties and those properties that differ from any predecessor styles that apply to a given element. In other words, each style only needs to include the properties that make it unique and different from other styles. There's no need to explicitly define every possible property of every style.
Unfortunately, many Web builders don't take advantage of this feature. Instead, they often feel compelled to pad their styles with rules for every applicable attribute. Although it's tempting to play it safe by specifying all of the important properties of a style instead of leaving some attributes to the unseen magic of the cascade, the result is bloated code.
Another common problem that plagues many Web builders is the overuse of classes and IDs. Adding classes and IDs to your markup and defining CSS styles to format those elements is one of the fundamentals of working with CSS. However, it's all too easy to get in the mindset of automatically creating a class for every little thing that you want to format. It's often much more efficient to redefine the properties of an HTML tag than it is to create a new class to overlay those properties on the element in question.
Another way to reduce the number of class styles you need in your style sheet is to apply multiple styles to the same page element instead of creating another style that simply combines the properties of two existing styles.
Code for the best, test for the rest
Believe it or not, the primary browser that you use for viewing your Web pages during development can have a significant effect on how you build your CSS style sheets.
Because of its overwhelming market share, many Web developers routinely use Internet Explorer as their primary browser. They first develop the site to look good in the browser used by most of their visitors, and then make whatever adjustments are necessary to deal with differences in the way other browsers render the site. It seems like a logical approach.
The problem is that IE is arguably the least standards-compliant of all the major browsers. Consequently, using IE to preview your code during development inevitably results in reflections of IE's many idiosyncrasies being embedded into the code. Then, to adapt that code to work on a more standards-compliant browser, you often need to rework substantial portions of the code.
Hopefully, the current problems with IE will eventually go away as we move toward a world where browsers and Web sites both conform to standards. With that future in mind, it makes more sense to develop your code according to those standards, and then add whatever temporary accommodations are necessary to make your site work on today's less-than-optimal browser.
The browser hacks that are needed to adapt standards-compliant code for display on older browsers are well documented. It's usually much easier to add (and later remove) those hacks than to rework your code to remove browser-specific idiosyncrasies.
If the goal is to produce standards-compliant code, then it makes sense to preview that code with the most standards-compliant browser available. Today, that's probably Mozilla's Firefox. (The availability of the Web developer toolbar extension is another powerful argument in favor of the Firefox browser.) After you get the effect you want in that browser, it's time to test your page in other browsers and begin the process of adding hacks and code tweaks to deal with browser compatibility issues.
If you follow this advice, you'll still spend a lot of time looking at your site in IE. It's just that you'll see it first in another browser—and your code just might be a little cleaner as a result.