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.

Avoid “class-itus”

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

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