CHAPTER 11: Cascading Style Sheets (CSS)

HTML and CSS

In many ways, the Cascading Style Sheets (CSS) specification represents a unique development in the history of the World Wide Web. In its inherent ability to allow richly styled structural documents, CSS is both a step forward and a step backward--but it's a good step backward, and a needed one. To see what is meant by this, it is first necessary to understand how the Web got to the point of desperately needing something like CSS, and how CSS makes the web a better place for both page authors and web surfers.

The Web's Fall from Grace

Back in the dimly remembered early years of the Web (1990-1993), HTML was a fairly lean little language. It was almost entirely composed of structural elements that were useful for describing things like paragraphs, hyperlinks, lists, and headings. It had nothing even remotely approaching tables, frames, or the complex markup we assume is a necessary part of creating web pages. The general idea was that HTML would be a structural markup language, used to describe the various parts of a document. There was very little said about how these parts should be displayed. The language wasn't concerned with appearance. It was just a clean little markup scheme.

Then came Mosaic.

Suddenly, the power of the World Wide Web was obvious to almost anyone who spent more than ten minutes playing with it. Jumping from one document to another was no harder than pointing the mouse cursor at a specially colored bit of text, or even an image, and clicking the mouse button. Even better, text and images could be displayed together, and all you needed to create a page was a plain text editor. It was free, it was open, and it was cool.

Web sites began to spring up everywhere. There were personal journals, university sites, corporate sites, and more. As number of sites increased, so did the demand for new HTML tags that would allow one effect or another. Authors started demanding that they be able to make text boldfaced, or italicized.

At the time, HTML wasn't equipped to handle these sorts of desires. You could declare a bit of text to be emphasized, but that wasn't necessarily the same as being italicized--it could be boldfaced instead, or even normal text with a different color, depending on the user's browser and their preferences. There was nothing to ensure that what the author created was what the reader would see.

As a result of these pressures, markup elements like <B> and <I> started to creep into the language. Suddenly, a structural language started to become presentational.

What a Mess

Years later, we have inherited the flaws inherent in this process. Large parts of HTML 3.2 and HTML 4.0, for example, are devoted to presentational considerations. The ability to color and size text through the FONT element, to apply background colors and images to documents and tables, to space and pad the contents of table cells, and to make text blink on and off are all the legacy of the original cries for "more control!"

If you want to know why this is a bad thing, all it takes is a quick glance at any corporate web site's page markup. The sheer amount of markup in comparison to actual useful information is astonishing. Even worse, for most sites, the markup is almost entirely made up of tables and FONT tags, none of which conveys any real semantic meaning to what's being presented. From a structural standpoint, these pages are little better than random strings of letters.

For example, let's assume that for page titles, an author is using FONT tags instead of heading tags like H1, like this:

<FONT SIZE="+3" FACE="Helvetica" COLOR="red">Page Title</FONT>

Structurally speaking, the FONT tag has no meaning. This makes the document far less useful. What good is a FONT tag to a speech-synthesis browser, for example? If an author uses heading tags instead of FONT tags, the speaking browser can use a certain speaking style to read the text. With the FONT tag, the browser has no way to know that the text is any different from other text.

Why do authors run roughshod over structure and meaning like this? Because they want readers to see the page as they designed it. To use structural HTML markup is to give up a lot of control over a page's appearance, and it certainly doesn't allow for the kind of densely packed page designs that have become so popular over the years.

So what's wrong with this? Consider the following:

Granted, a fully structured document is a little plain. Due to that one single fact, a hundred arguments in favor of structural markup wouldn't sway a marketing department away from the kind of HTML so prevalent at the end of the twentieth century. What was needed was a way to combine structural markup with attractive page presentation.

This concept is nothing new. There have been many style sheet technologies proposed and created over the last few decades. These were intended for use in various industries and in conjunction with a variety of structural markup languages. The concept had been tested, used, and generally found to be a benefit to any environment where structure had to be presented. However, no style sheet solution was immediately available for use with HTML. Something had to be done to correct this problem.

CSS to the Rescue

Of course, the problem of polluting HTML with presentational markup was not lost on the World Wide Web Consortium (W3C). It was recognized early on that this situation couldn't continue forever, and that a good solution was needed quickly. In 1995, they started publicizing a work-in-progress called CSS. By 1996, it had become a full Recommendation, with the same weight as HTML itself.

So what does CSS offer us? As of this writing, it offers us two levels of itself. The first level is Cascading Style Sheets, Level 1 (CSS1), which was made a full W3C Recommendation in 1996. Soon thereafter, the W3C's Cascading Style Sheets and Formatting Properties (CSS&FP) Working Group got to work on a more advanced specification, and in 1998 their work paid off when Cascading Style Sheets, Level 2 (CSS2) was made a full Recommendation. CSS2 builds on CSS1 by extending the earlier work without making major changes to it.

The future is likely to see further advances in CSS, but until then, let's go over what we already have.

Ease of Use

If the depth of CSS doesn't convince you, then perhaps this will: style sheets can drastically reduce a web author's workload.

Style sheets can do this by centralizing the commands for certain visual effects in one handy place, instead of scattering them throughout the document. As an example, let's say you want all of the headings in a document to be purple. (No, I don't know why you would want this, but assume with me.) Using HTML, the way to do this would be to put a FONT tag in every heading tag, like so:

<H2><FONT COLOR="purple">This is purple!</FONT></H2>

This has to be done for every heading of level two. If you have forty headings in your document, you have to insert forty FONT tags throughout, one for each heading! That's a lot of work for one little effect.

But let's assume that you've gone ahead and put in all those FONT tags. You're done, you're happy--and then you decide (or your boss decides for you) that headings should really be dark green, not purple. Now you have to go back and fix every single one of those FONT tags. Sure, you might be able to find-and-replace, as long as headings are the only purple text in your document. If you've put other purple FONT tags in your document, then you can't find-and-replace, because you'd affect them too.

It would be much better to have a single rule instead:

H2 {color: purple;}

Not only is this faster to type, but it's easier to change. If you do switch from purple to dark green, all you have to change is that one rule.

Let's go back to the highly styled H1 element from the previous section:

H1 {color: maroon; font: italic 1em Times, serif; text-decoration: underline;
   background: yellow;}

This may look like it's worse to write than using HTML, but consider a case where you have a page with about a dozen H2 elements that should look the same as the H1. How much markup will be required for those 12 H2 elements? A lot. On the other hand, with CSS, all you need to do is this:

H1, H2 {color: maroon; font: italic 1em Times, serif; text-decoration: underline;
   background: yellow;}

Now the styles apply to both H1 and H2 elements, with just three extra keystrokes.

If you want to change the way H1 and H2 elements look, the advantages of CSS become even more striking. Consider how long it would take to change the HTML markup for all H1 and 12 H2 elements, compared to changing the previous styles to this:

H1, H2 {color: navy; font: bold 1em Helvetica, sans-serif;
   text-decoration: underline overline; background: silver;}

If the two approaches were timed on a stopwatch, I'm betting the CSS-savvy author would handily beat the HTML jockey.

In addition, most CSS rules are collected into one location in the document. It is possible to scatter them throughout the document by associated styles to individual elements, but it's usually far more efficient to place all of your styles into a single style sheet. This lets you create (or change) the appearance of an entire document in one place.

Using Your Styles on Multiple Pages

But wait--there's more! Not only can you centralize all of the style information for a page in one place, but you can also create a style sheet that can then be applied to multiple pages--as many as you like. This is done by a process in which a style sheet is saved to its own document, and then imported by any page for use with that document. Using this capability, you can quickly create a consistent look for an entire web site. All you have to do is link the single style sheet to all of the documents on your web site. Then, if you ever want to change the look of your site's pages, you need only edit a single file and the change will be propagated throughout the entire server--automatically!

Consider a site where all of the headings are gray on a white background. They get this color from a style sheet that says:

H1, H2, H3, H4, H5, H6 {color: gray; background: white;}

Now, let's say this site has 700 pages, each one of which uses the style sheet that says headings should be gray. At some point, it's decided that headings should be white on a gray background. So the site's webmaster edits the style sheet to say:

H1, H2, H3, H4, H5, H6 {color: white; background: gray;}

Then he saves the style sheet to disk, and the change is made. That sure beats having to edit 700 pages to enclose every heading in a table and a FONT tag, doesn't it?

Cascading

And that's not all! CSS also makes provisions for conflicting rules; these provisions are collectively referred to as the cascade. For instance, take the previous scenario in which you're importing a single style sheet into a whole bunch of web pages. Now inject a set of pages that share many of the same styles, but also have specialized rules that apply only to them. You can create another style sheet that is imported into those pages, in addition to the already existing style sheet, or you can just place the special styles into the pages that need them.

For example, you might have one page out of the 700 where headings should be yellow on dark blue instead of white on gray. In that single document, then, you could insert this rule:

H1, H2, H3, H4, H5, H6 {color: yellow; background: blue;}

Thanks to the cascade, this rule will override the imported rule for white-on-gray headings. By understanding the cascade rules and using them to your advantage, you can create highly sophisticated sheets that come together to give your pages a professional yet easily changed look.

This ability is not confined to just the author. Web surfers (or readers) can, in some browsers, create their own style sheets (called reader style sheets, oddly enough) that will cascade with the author's styles as well as the styles used by the browser. Thus, a reader who is color-blind could create a style that makes hyperlinks stand out:

A:link {color: white; background: black;}

A reader style sheet could contain almost anything: a directive to make text large enough to read, if the user has impaired vision; rules to remove images for faster reading and browsing; even styles to place the user's favorite picture in the background of every document. (This isn't recommended, of course, but it is possible.) This lets readers customize their web experience without having to turn off all of the author's styles.

Between importing, cascading, and its variety of effects, CSS becomes a wonderful tool for any author or reader.

Compact File Size

Besides the visual power of CSS and its ability to empower both author and reader, there is something else about it that your readers will like. It can help keep document sizes as small as possible, thereby speeding download times. How? As we've mentioned, a lot of pages have used tables and FONT tags to achieve nifty visual effects. Unfortunately, both of these methods create a lot of HTML markup, and that drives up file sizes. By grouping visual style information into central areas and representing those rules using a fairly compact syntax, you can remove the FONT tags and other bits of the usual tag soup. Thus, CSS can keep your load times low and your reader satisfaction high.

Preparing for the Future

HTML, as I previously pointed out, is a structural language, while CSS is its complement: a stylistic language. Recognizing this, the World Wide Web Consortium (W3C), the body that debates and approves standards for the Web, is beginning to remove stylistic tags from HTML. The reasoning for this move is that style sheets can be used to create the effects that certain HTML tags provide, so who needs them?

As of this writing, the HTML 4.0 specification has a number of tags that are deprecated; that is, they are in the process of being phased out of the language altogether. Eventually, they will be marked as obsolete, which means that browsers will be neither required nor encouraged to support them. Among the deprecated tags are <FONT>, <BASEFONT>, <U>, <STRIKE>, <S>, and <CENTER>. With the advent of style sheets, none of these HTML tags are necessary.

As if that weren't enough, there is the very strong possibility that HTML will be gradually replaced by the Extensible Markup Language (XML). XML is much more complicated than HTML, but it is also far more powerful and flexible. Despite this, XML does not, of itself, provide any way to declare style tags such as <I> or <CENTER>. Instead, it is quite probable that XML documents will rely on style sheets to determine the appearance of documents. While the style sheets used with XML may not be CSS, they will probably be whatever follows CSS and very closely resembles it. Therefore, learning CSS now will give authors a big advantage when the time comes to make the jump to an XML-based Web.

Limitations of CSS

There are a few areas that CSS1 does not address, and therefore are not covered in detail in this book; some of these topics are touched upon in Chapter 10, CSS2: A Look Ahead. Of course, even a full-blown CSS implementation, covering all of CSS1 and CSS2, would not meet every request from every page designer in the world. It's worth going through some of the boundaries of CSS.

Limited Initial Scope

When you get right down to it, CSS1 is not an overly complicated specification. The entire thing can be printed out in less than 100 pages, and it contains about 70 properties. It is still a very sophisticated and subtle engine, but some areas of web design were omitted from CSS1.

In the first place, CSS1 had almost nothing to say about tables. You might think that you can set margins on table cells, for example--and a web browser might even let you do so--but margins should not be applied to table cells under any circumstances. CSS2 introduced a new set of properties and behaviors for dealing with tables, but as of this writing, few if any of these are supported.

TIP:

To a certain degree, the omission of tables from CSS1 says a great deal about the feeling many have that tables should never be used to lay out pages. It is felt that floated and positioned elements should do all of the work tables used to do, and more. Whether this premise can be supported is not a discussion I intend to undertake here.

In a similar way, CSS1 contains nothing in the way of positioning. Sure, it's possible to move elements around a little bit, but mostly with negative margins and floating. Everything is, in a sense, relative. CSS2, on the other hand, has three chapters devoted to the visual rendering model, which includes the positioning of elements.

CSS1 makes no provision for downloadable fonts. This leads to a good deal of discussion about how to account for user system configurations and available fonts. CSS2 introduces some font-handling, but even there the issue is not resolved, mostly due to the lack of a widely supported font format. It may be that Scalable Vector Graphics (SVG) will solve some or all of this problem, but it is impossible at this point to say with any certainty.

Finally, there is a lack of media types in CSS1. In other words, CSS1 is primarily a screen-device language, intended to be used to put content onto a computer monitor. There is some thought toward paged media, like printouts, but not much. (Despite this, CSS1 is not a pixel-perfect control mechanism.) In an effort to overcome this limitation, CSS2 introduces media types, which makes it possible to create separate style sheets that are applied to a document depending on its display media. CSS2 also introduces properties and behavior specifically aimed at paged media and aural media.

Implementations

Sadly, the major drawback to using CSS is that it was so poorly implemented at first. Through a combination of miscommunication, misinterpretation, confusion, and poor quality control, the first browsers to attempt support of CSS did a rather poor job of it.

The worst offenders are Microsoft Internet Explorer 3.x and Netscape Navigator 4.x. The first in their respective lines to attempt CSS support, these browsers have incomplete, bug-ridden, and quite often contradictory implementations of CSS1, never mind CSS2. These implementations are so bad that it is difficult to consider them CSS-supporting at all. Some of their flaws are bad enough to cause the browser to crash, or even lock up an entire system, when trying to handle some styles.

With Internet Explorer 4.x and 5.x, things did improve. Although not perfect by any means, these browser versions did at least stomp out many of the bugs that plagued IE3, and also added some support for previously unrecognized CSS properties in both CSS1 and CSS2.

Opera 3.5, on the other hand, came out of the gate with impressive CSS support. Confining itself to CSS1, this browser did quite well with the properties that it supported, suffering only a few minor bugs. When 3.6 was released, almost all of these bugs were eliminated, although support did not move past CSS1. Before version 3.5, Opera did not support CSS at all.

As for Netscape's products, the Navigator 4.7 is not significantly better at CSS support than was version 4.0, although it's at least less crash-prone. The only real hope for good CSS support out of Netscape is their Gecko rendering engine. As this was being written, the latest builds of Gecko were quite excellent, and were in fact used (along with Internet Explorer 4.5 and 5.0 for Macintosh) to create many of the figures in this book.

Since CSS is not intended to provide total control over document display, and should allow the page's content to come through no matter what browser is being used, this general state of affairs should not be considered a barrier to the use of CSS. You may wish, however, to warn your users that if they are using browsers of a certain vintage (Explorer 3.x, and perhaps Navigator 4.x) that they go into their preferences and disable style sheets. That way, they'll at least be able to read the content of your pages, even if it isn't styled the way you might have hoped.

Bringing CSS and HTML Together

We keep visiting the point that HTML documents have an inherent structure. In fact, that's part of the problem with the Web today: too many of us forget that documents are supposed to have an internal structure, which is altogether different than a visual structure. In our rush to create the coolest-looking pages on the Web, we've bent, warped, and generally ignored the idea that pages should contain information that has some structural meaning.

However, that structure is an inherent part of the relationship between HTML and CSS; without the structure, there couldn't be a relationship at all. In order to understand it better, let's look at an example HTML document and break it down by pieces. Here's the markup, shown in Figure 1-1:

<HTML>
<HEAD>
    <TITLE>Eric's World of Waffles</TITLE>
    <LINK REL="stylesheet" TYPE="text/css" HREF="sheet1.css" TITLE="Default">
    <STYLE TYPE="text/css">
        @import url(sheet2.css);
        H1 {color: maroon;}
        BODY {background: yellow;}
        /* These are my styles! Yay! */
    </STYLE>
</HEAD>
<BODY>
    <H1>Waffles!</H1>
    <P STYLE="color: gray;">The most wonderful of all breakfast foods is
    the waffle-- a ridged and cratered slab of home-cooked, fluffy
    goodness...
    </P>
</BODY>
</HTML>

Figure 1-1. A simple document

 

Now, let's examine each portion of the document.

The LINK Tag

<LINK REL="stylesheet" TYPE="text/css" HREF="sheet1.css" TITLE="Default">

First we consider the use of the LINK tag. The LINK tag is a little-regarded but nonetheless perfectly valid tag that has been hanging around the HTML specification for years, just waiting to be put to good use. Its basic purpose is to allow HTML authors to associate other documents with the document containing the LINK tag. CSS1 uses it to link style sheets to the HTML document; in Figure 1-2, a style sheet called sheet1.css is linked to the document.

Figure 1-2. A representation of how external style sheets are applied to documents

 

These style sheets, which are not part of the HTML document but are still used by it, are referred to as external style sheets. This is due to the fact that they're style sheets but are external to the HTML document. (Go figure.)

In order to successfully load an external style sheet, LINK must be placed inside the HEAD element but may not be placed inside any other element, rather like TITLE or STYLE. This will cause the web browser to locate and load the style sheet and use whatever styles it contains to render the HTML document, in the manner shown in Figure 1-2.

And what is the format of an external style sheet? It's simply a list of rules, just like those we saw in the previous section and in the example above, but in this case, the rules are saved into their own file. Just remember that no HTML or any other markup language can be included in the style sheet--only style rules. Here's the markup of an external style sheet:

H1 {color: red;}
H2 {color: maroon; background: white;}
H3 {color: white; background: black; font: medium Helvetica;}

That's all there is to it--no STYLE tags, no HTML tags at all, just plain-and-simple style declarations. These are saved into a plain text file and are usually given an extension of .css, as in sheet1.css.

The filename extension is not required, but some browsers won't recognize the file as containing a style sheet unless it actually ends with .css, even if you do include the correct TYPE of text/css in the LINK element. So make sure you name your style sheets appropriately.

LINK attributes

For the rest of the LINK tag, the attributes and values are fairly straightforward. REL stands for "relation," and in this case, the relation is "stylesheet." TYPE is always set to text/css. This value describes the type of data that is to be loaded using the LINK tag. That way, the web browser knows that the style sheet is a CSS style sheet, a fact that will determine how the browser deals with the data it imports. After all, there may be other style languages in the future, so it will be important to say which language you're using.

Next we find the HREF attribute. The value of this attribute is the URL of your style sheet. This URL can be either absolute or relative, depending on what works for you. In our example, of course, the URL is relative. It could as easily have been something like http://www.style.org/sheet1.css.

Finally, there is the TITLE attribute. This attribute is not often used, but it could become important in the future. Why? It becomes important when there is more than one LINK tag--and there can be more than one. In these cases, however, only those LINK tags with a REL of stylesheet will be used in the initial display of the document. Thus, if you wanted to link in two style sheets with the names basic.css and splash.css, the markup would look like this:

<LINK REL="stylesheet" TYPE="text/css" HREF="basic.css">
<LINK REL="stylesheet" TYPE="text/css" HREF="splash.css">

This will cause the browser to load both style sheets, combine the rules from each, and apply the result to the document (see Figure 1-3). We'll see exactly how the sheets are combined in the next chapter, but for now, let's just accept that they're combined. For example:

<LINK REL="stylesheet" TYPE="text/css" HREF="sheet-a.css">
<LINK REL="stylesheet" TYPE="text/css" HREF="sheet-b.css">
 
<P CLASS="a1">This paragraph will be gray only if styles from the
stylesheet 'sheet-a.css' are applied.</P>
<P CLASS="b1">This paragraph will be gray only if styles from the
stylesheet 'sheet-b.css' are applied.</P>

Figure 1-3. Combining linked style sheets

 

It's also possible to define alternate style sheets. These are marked with a REL of alternate stylesheet and come into play only if they're selected by the reader.

Alternate style sheets

Unfortunately, as of this writing, browsers don't make it very easy to select alternate style sheets, assuming that they can do so at all. Should a browser be able to use alternate style sheets, it will use the values of the TITLE attributes to generate a list of style alternatives. So you could write the following:

<LINK REL="stylesheet" TYPE="text/css"
 HREF="sheet1.css" TITLE="Default">
<LINK REL="alternate stylesheet" TYPE="text/css"
 HREF="bigtext.css" TITLE="Big Text">
<LINK REL=" alternate stylesheet " TYPE="text/css"
 HREF="spoken.css" TITLE="Spoken Word">

Users could then pick the style they wanted to use, and the browser would switch from the first one (labeled "Default" in this case) to whichever the reader picked. Figure 1-4 shows one way in which this selection mechanism might be accomplished.

Figure 1-4. A browser offering alternate style sheet selection

 

WARNING:  

Alternate styles sheets are only supported by one browser as of this writing--Internet Explorer for Macintosh--and that only with a JavaScript widget, which does not ship with the browser. None of the three major browsers natively supports the selection of alternate style sheets (shown in Figure 1-4).

As of this writing, the one browser that does recognize alternate style sheets (Internet Explorer for Macintosh) will not apply the styles from any LINK element with a REL of alternate stylesheet unless that style sheet is selected by the user.

The STYLE Element

The STYLE element, which is a relatively new element in HTML, is the most common way to define a style sheet, since it appears in the document itself. STYLE should always use the attribute TYPE; in the case of a CSS1 document, the correct value is text/css, just as it was with the LINK tag. So, the STYLE container should always start with <STYLE TYPE="text/css">. This is followed by one or more styles and finished with a closing </STYLE> tag.

The styles between the opening and closing STYLE tags are referred to as the document style sheet or the embedded style sheet, since this style sheet is embedded within the document. It contains styles that apply to the document, but it can also contain multiple links to external style sheets using the @import directive.

The @import Directive

Now for the stuff that is found inside the STYLE tag. First, we have something very similar to LINK: the @import directive. Just like LINK, @import can be used to direct the web browser to load an external style sheet and use its styles in the rendering of the HTML document. The only real difference is in the actual syntax of the command and its placement. As you can see, @import is found inside the STYLE container. It must be placed there, before the other CSS rules, or else it won't work at all.

<STYLE TYPE="text/css">
@import url(styles.css); /* @import comes first */
H1 {color: gray;}
</STYLE>

Like LINK, there can be more than one @import statement in a document. Unlike LINK, however, the style sheets of every @import directive will always be loaded and used. So given the following, all three external style sheets will be loaded, and all of their style rules will be used in the display of this document:

@import url(sheet2.css);
@import url(blueworld.css);
@import url(zany.css);

WARNING:  

Only Internet Explorer 4.x/5.x and Opera 3.x support @import; Navigator 4.x ignores this method of applying styles to a document. This can actually be used to one's advantage in "hiding" styles from these browsers. See Chapter 11, CSS in Action, for more details.

Actual Styles

H1 {color: maroon;}
BODY {background: yellow;}

After the @import statement in our example, we find some ordinary styles. What they mean doesn't actually matter for this discussion, although you can probably guess that they set H1 elements to be maroon and BODY elements to have a yellow background.

Styles such as these comprise the bulk of any embedded style sheet--style rules both simple and complex, short and long. It will be only rarely that you have a document where the STYLE element does not contain any rules.

For those of you concerned about making your documents accessible to older browsers, there is an important warning to be made. You're probably aware that browsers ignore tags they don't recognize; for example, if a web page contains a BLOOPER tag, browsers will completely ignore the tag because it isn't a tag they recognize.

The same will be true with style sheets. If a browser does not recognize <STYLE> and </STYLE>, it will ignore them altogether. However, the declarations within those tags will not be ignored, because they will appear to be ordinary text so far as the browser is concerned. So your style declarations will appear at the top of your page! (Of course, the browser should ignore the text because it isn't part of the BODY element, but this is never the case.) This problem is illustrated in Figure 1-5.

Figure 1-5. Older browsers will literally display your style sheets

In order to combat this problem, it is recommended that you enclose your declarations in a comment tag. In the example given here, the beginning of the comment tag appears right after the opening STYLE tag, and the end of the comment appears right before the closing STYLE tag: 

<STYLE type="text/css"><!--
@import url(sheet2.css);
H1 {color: maroon;}
BODY {background: yellow;}
--></STYLE>

This should cause older browsers to completely ignore not only the STYLE tags but the declarations as well, because HTML comments are not displayed. Meanwhile, those browsers that understand CSS will still be able to read the style sheet.

WARNING:

There is one drawback to this strategy. A few versions of older browsers, such as very early versions of Netscape Navigator and NCSA Mosaic, had some trouble with comments. The problems ranged from mangled display to browser crashes. This happened with only a very few browser versions, and it's safe to say that very few of these browsers are still being operated. Be aware that there are some people out there using these particular browsers, and they may well have major problems viewing your page if you use these comment tags.

CSS Comments

/* These are my styles! Yay! */

CSS also allows for comments, but it uses a completely different syntax to accomplish this. CSS comments are very similar to C/C++ comments, in that they are surrounded by /* and */:

/* This is a CSS1 comment */

Comments can span multiple lines, just as in C++:

/* This is a CSS1 comment, and it
can be several lines long without
any problem whatsoever. */

It's important to remember that CSS comments cannot be nested. So, for example, this would not be correct:

/* This is a comment, in which we find
another comment, which is WRONG
   /* Another comment */
and back to the first comment */

However, it's hardly ever desirable to nest comments, so this limitation is no big deal.

If you wish to place comments on the same line as markup, then you need to be careful about how you place them. For example, this is the correct way to do it:

H1 {color: gray;}   /* This CSS comment is several lines */
H2 {color: silver;} /* long, but since it is alongside */
P {color: white;}   /* actual styles, each line needs to */
PRE {color: gray;} /* be wrapped in comment markers. */

Given this example, if each line isn't marked off, then most of the style sheet will become part of the comment, and so will not work:

H1 {color: gray;}   /* This CSS comment is several lines
H2 {color: silver;}   long, but since it is not wrapped
P {color: white;}   in comment markers, the last three
PRE {color: gray;}   styles are part of the comment. */

In this example, only the first rule (H1 {color: gray;}) will be applied to the document. The rest of the rules, as part of the comment, are ignored by the browser's rendering engine.

Moving on with our example, we see some more CSS information actually found inside an HTML tag!

Inline Styles

<P STYLE="color: gray;">The most wonderful of all breakfast foods is
the waffle-- a ridged and cratered slab of home-cooked, fluffy goodness...
</P>

For cases where you want to simply assign a few styles to one individual element, without the need for embedded or external style sheets, you'll employ the HTML attribute STYLE to set an inline style. The STYLE attribute is new to HTML, and it can be associated with any HTML tag whatsoever, except for those tags which are found outside of BODY (HEAD or TITLE, for instance).

The syntax of a STYLE attribute is fairly ordinary. In fact, it looks very much like the declarations found in the STYLE container, except here the curly brackets are replaced by double quotation marks. So <P STYLE="color: maroon; background: yellow;"> will set the text color to be maroon and the background to be yellow for that paragraph only. No other part of the document will be affected by this declaration.

Summary

In order to facilitate a return to structural HTML, something was needed to permit authors to specify how a document should be displayed. CSS fills that need very nicely, and far better than the various presentational HTML elements ever did (or probably could have done). For the first time in years, there is hope that web pages can become more structural, not less, and at the same time the promise that they can have a more sophisticated look than ever before.

In order to ensure that this transition goes as smoothly as possible, HTML introduces a number of ways to link HTML and CSS together while still keeping them distinct. This allows authors to simplify document appearance management and maximize their effectiveness, thereby making their jobs a little easier. The further benefits of improving accessibility and positioning documents for a switch to an XML world make CSS a compelling technology.

As for user agent support, the LINK element has been universally supported, as have both the STYLE element and attribute. @import didn't fare so well, though, being ignored outright by Navigator 4. This is not such a major tragedy, annoying though it might be, since the LINK element will still let you bring external style sheets into play.

In order to fully understand how CSS can do all of this, authors need a firm grasp of how CSS handles document structure, how one writes rules that behave as expected, and most of all, what the "Cascading" part of the name really means.

This tutorial shamefully extracted (and cleaned up) from this site.