Cascading style sheets (CSS) are an elegantly designed extension to the Web and one of the greatest hopes for recapturing the Web's ideal of separation of presentation and content. The Web is the ultimate cross-platform system, and your content will be presented on such a huge variety of devices that pages should specify the meaning of the information and leave presentation details to a merger (or "cascade") of site-specified style sheets and the user's preferences. If the introduction of WebTV broke your pages, you will appreciate the ability to introduce new page designs by creating a single style sheet file rather than by modifying thousands of content pages.
Use a single style sheet for all of the pages on your site (or possibly a few coordinated ones if you have pages with very different needs: for example technical documentation versus marketing pages). One of the main benefits of style sheets is to ensure visual continuity as the user navigates your site. Legacy publications have long known the value of basing print products on a single typeface: no matter where you turn in a magazine or a newspaper, the text and basic layout will look the same. Websites will gain the same brand cohesiveness if all the pages on a site link to the same style sheet.
Always use linked style sheets rather than embedded styles. Only by referencing an external file will you get the maintenance benefits of being able to update the look of your entire site with a single change. Also, by pulling style definitions out of your pages, you make them smaller and faster to download. If you use a single style sheet for your entire site, that file will be a single download once and for all.
For each site, all the style sheets should be designed by a single, central design group. Two reasons: First, centralized design is the only way to ensure a consistent style and reap one of the main benefits of style sheets. Second, the majority of Web content creators are not capable of designing and writing good style sheets. Experience with word processors that support style sheets indicates that most authors mangle their style sheets terribly. Understanding the effect of style is relatively easy in traditional desktop publishing because it is a WYSIWYG environment with a single, canonical output form. The Web is not WYSIWYG because of the variability in supported platforms. Furthermore, Web stylesheets are cascading, meaning that the site's style sheet is merged with the user's style sheet to create the ultimate presentation. These differences make it important that Web style sheets are designed by a specialist who understands the many ways in which the result may look different than what is on his or her own screen.
Fund an active evangelism program to teach your content creators how to use the centrally defined style sheet. Do not assume that people understand the concept of style and how to apply it, simply because they know a word processor with style sheets. Research shows that most users make horrible mistakes in using word processing style sheets: partly because the main word processors have particularly bad style sheet usability and partly because style is hard. Your style sheet should come with a small manual that explains the different styles and when and how to use them. Include plenty of examples, including both raw HTML code (cutting-and-pasting examples is the main way people use documentation) and screenshots of the appearance of correctly coded pages in several mainstream browsers on several different platforms. The screenshots should be made into clickable imagemaps, allowing users to click on an effect they want to achieve and get to the documentation for the appropriate styles. In particular, if multiple styles have similar appearance, many errors can be avoided by explaining the differences and when to use which style.
Despite my preference for linked style sheets and central design, individual page authors should be allowed to create additional embedded styles for their own pages when necessary. Authors should be encouraged to only do so when absolutely necessary, but there will always be cases where a certain style is needed that is not supplied in the central style sheet. If many pages need the same effect, it should be added to the site's global style sheet, but it would be bad to inflate the one linked style sheet with styles that are only needed once. Single-page styles should be embedded rather than linked: the page should continue to link in the global style sheet and then override it with local, embedded styles as necessary. Doing so has the benefit of allowing future changes to the central style sheet to propagate to the modified page to the greatest extent possible.
Pages must continue to work when style sheets are disabled: for example, do not use tricks where the same words are repeated multiple times with small offsets to create shadow effects (without the intended style, the text turns into gibberish). Retaining a decent presentation without the style sheet is mandatory to support users with older browsers, blind users, and users who need to disable the style feature in their browser (either because of bugs or because your style conflicts too much with their preferences). Luckily, it is very easy to check conformance with this rule: simply disable style sheets in your browser and reload the page.
Do not use more than two fonts (plus possibly a third for special text like
computer code ). Remember the lesson from the early days of desktop publishing: using a lot of fonts simply because you can will result in a ransom-note look. Typically, you can use one typeface for body text and another, bolder, face for headings. Note that it is fine (indeed, recommended) to use a long list of alternate fonts in the style sheet specification for a given class of text: the user's browser will pick the first available font in the list and use it throughout your pages, meaning that the user will see a single font, making the site feel typographically unified. It is important that lists of font names have the fonts listed in the same order, since the browser picks the first one it has available.
Do not use absolute font sizes; instead specify all text relative to the base font size defined by the user's preference setting. For example, large text could be defined as "200%", meaning that it would be set as 24 point if the user preferred 12 point for body text and 20 point if the user preferred 10 point for body text. Whether people prefer large or small fonts depends on a variety of questions, including the size and resolution of their monitors and the user's eyesight. It is somewhat annoying to visit a website where the text is too small for comfortable reading under my circumstances, but it is very annoying to click on the "make text bigger" button and have nothing happen because the font sizes were defined as an absolute number of points.
Do not use the
!important attribute to override the user's settings. It is hard to imagine cases where you are justified in ignoring the user's preferences if the user felt strongly enough to use his or her own
!important rating, so
!important should be reserved for user style sheets.
If you have multiple style sheets, then make sure to use the same CLASS names for the same concept in all of the style sheets. Content creators using two or more style sheets will be confused if different CLASSes are used for the same thing or if one style sheet has a CLASS that is missing in the other style sheet even though the concept applied in both cases. If, for example, you have a CLASS for the name of the author of a document, then all of your style sheets should have this CLASS, even though it may be defined to render differently, as appropriate for the different kinds of documents.
Even though the CSS logo button is nice, I recommend that you restrain yourself and do not plaster it all over your site. In particular, do not put it on the home page. Users do not care how you implement your site (except if they follow a link to "about this site" - it would be great to put a CSS button on the "About" page). A firm rule for home page design is more is less : the more buttons and options you put on the home page, the less users are capable of quickly finding the information they need. (Because of this rule I am puzzled by the many home pages that feature download buttons for various browser vendors: why anybody would reduce the usability of their own site in order to give another company free advertising is beyond me.)