Read CSS: The Definitive Guide, 3rd Edition Online
Authors: Eric A. Meyer
Tags: #COMPUTERS / Web / Page Design
Cascading Style Sheets (CSS) are a powerful way to affect the presentation of a document
or a collection of documents.
Obviously, CSS is
basically useless without a document of some sort, since it would have no content to
present. Of course, the definition of "document" is extremely broad. For example, Mozilla
and related browsers use CSS to affect the presentation of the browser chrome itself.
Still, without the content of the chrome—buttons, address inputs, dialog boxes, windows,
and so on—there would be no need for CSS (or any other presentational information).
Back in the
dimly remembered, early years of the Web (1990–1993), HTML
was a
fairly lean language. It was composed almost entirely 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
necessary to create web pages. HTML was originally intended to be a structural markup
language, used to describe the various parts of a document; very little was said about
how those 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 10 minutes playing with it. Jumping
from one document to another was no more difficult than pointing the cursor at a
specially colored bit of text, or even an image, and clicking the mouse. 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 the number of sites increased, so did the demand
for new HTML elements that would each perform a specific function. Authors started
demanding that they be able to make text boldfaced or italicized.
At the time, HTML wasn't equipped to handle those 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 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
and
started to
creep into the language. Suddenly, a structural language started to become
presentational.
Years later, we have inherited the problems of this
haphazard process. Large parts of HTML 3.2 and HTML 4.0, for example, were devoted to
presentational considerations. The ability to color and size text through thefont
element, to apply background colors and
images to documents and tables, to usetable
attributes (such ascellspacing
), and to make text
blink on and off are all the legacy of the original cries for "more control!"
For an example of the mess in action, take a quick glance at almost any corporate
web site's markup. The sheer amount of markup in comparison to actual useful
information is astonishing. Even worse, for most sites, the markup is almost entirely
comprised of tables andfont
elements, neither of
which conveys any real semantic meaning as 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 usesfont
elements instead of heading elements likeh1
:
Page Title
Structurally speaking, thefont
tag has no
meaning. This makes the document far less useful. What good is afont
tag to a speech-synthesis browser, for example? If
an author uses heading elements instead offont
elements, though, the speaking browser can use a certain speaking style to read the
text. With thefont
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 this way? 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. But consider
the following problems with such an approach:
Unstructured pages make content indexing inordinately difficult. A truly
powerful search engine would allow users to search only page titles, or only
section headings within pages, or only paragraph text, or perhaps only those
paragraphs that are marked as important. To accomplish such a feat, however,
the page contents must be contained within some sort of structural
markup—exactly the sort of markup most pages lack. Google, for example, does
pay attention to markup structure when indexing pages, so a structural page
will increase your Google rank.
Lack of structure reduces accessibility. Imagine that you are blind and rely
on a speech-synthesis browser to search the Web. Which would you prefer: a
structured page that lets your browser read only section headings so that you
can choose which section you'd like to hear more about; or a page that is so
lacking in structure that your browser is forced to read the entire thing with
no indication of what's a heading, what's a paragraph, and what's important?
Let's return to Google—the search engine is, in effect, the world's most active
blind user, with millions of friends who accept its every suggestion about
where to surf and shop.
Advanced page presentation is possible only with some sort of document
structure. Imagine a page in which only the section headings are shown, with an
arrow next to each. The user can decide which section heading applies to him
and click on it, thus revealing the text of that section.
Structured markup is easier to maintain. How many times have you spent
several minutes hunting through someone else's HTML (or even your own) in
search of the one little error that's messing up your page in one browser or
another? How much time have you spent writing nested tables andfont
elements, only to get a sidebar with white
hyperlinks in it? How many linebreak elements have you inserted trying to get
exactly the right separation between a title and the following text? By using
structural markup, you can clean up your code and make it easier to find what
you're looking for.
Granted, a fully structured document is a little plain. Due to that one single
fact, a hundred arguments in favor of structural markup won't sway a marketing
department from using the type of HTML that was so prevalent at the end of the 20th
century, and which persists even today. What we need is a way to combine structural
markup with attractive page presentation.
Of
course, the problem of polluting HTML with presentational markup
was not lost on the World Wide Web Consortium
(W3C),
which began searching for a quick solution. In
1995, the consortium started publicizing a work-in-progress called CSS. By 1996, it had
become a full Recommendation, with the same weight as HTML itself. Here's why.
In the first place, CSS allows for much richer document appearances than HTML ever
allowed, even at the height of its presentational fervor. CSS lets you set colors on
text and in the background of any element; permits the creation of borders around any
element, as well as the increase or decrease of the space around them; lets you
change the way text is capitalized, decorated (e.g., underlining), spaced, and even
whether it is displayed at all; and allows you to accomplish many other effects.
Take, for example, the first (and main) heading on a page, which is usually the
title of the page itself. The proper markup is:
Leaping Above The Water
Now, suppose you want this title to be dark red, use a certain font, be italicized
and underlined, and have a yellow background. To do all of that with HTML, you'd have
to put theh1
into a table and load it up with a
ton of other elements likefont
andU
. With CSS, all you need is one rule:
h1 {color: maroon; font: italic 2em Times, serif; text-decoration: underline;
background: yellow;}
That's it. As you can see, everything you did in HTML can be done in CSS. There's
no need to confine yourself to only those things HTML can do, however:
h1 {color: maroon; font: italic 2em Times, serif; text-decoration: underline;
background: yellow url(titlebg.png) repeat-x;
border: 1px solid red; margin-bottom: 0; padding: 5px;}
You now have an image in the background of theh1
that is only repeated horizontally, and a border around it, separated
from the text by at least five pixels. You've also removed the margin (blank space)
from the bottom of the element. These are feats that HTML can't even come close to
matching—and that's just a taste of what CSS can do.
If the
depth of CSS doesn't convince you, then perhaps this will: style sheets
can drastically reduce a web author's workload.
First, style sheets centralize 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 theh2
headings in a document
to be purple. Using HTML, the way to do this would be to put afont
tag in every heading, like so:
This is purple!
This must be done for every heading of level two. If you have 40 headings in your
document, you have to insert 40font
elements
throughout, one for each heading! That's a lot of work for one little effect.
Let's assume that you've gone ahead and put in all thosefont
elements. You're done, you're happy—and then you decide (or your
boss decides for you) that thoseh2
headings
should really be dark green, not purple. Now you have to go back and fix every single
one of thosefont
elements. 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 purplefont
elements
in your document, then you
can't
find-and-replace because you'd
affect those, 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 styledh1
element
from the previous section:
h1 {color: maroon; font: italic 2em Times, serif; text-decoration: underline;
background: yellow;}
This may look like it's worse to write than HTML, but consider a case where you
have a page with about a dozenh2
elements that
should look the same as theh1
. How much markup
will be required for those 12h2
elements? A lot.
On the other hand, with CSS, all you need to do is this:
h1, h2 {color: maroon; font: italic 2em Times, serif; text-decoration: underline;
background: yellow;}
Now the styles apply to bothh1
andh2
elements, with just three extra keystrokes.
If you want to change the wayh1
andh2
elements look, the advantages of CSS are even more
striking. Consider how long it would take to change the HTML markup for anh1
and 12h2
elements, compared to changing the previous styles to this:
h1, h2 {color: navy; font: bold 2em 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 easily 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 grouping them into associated
styles or 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.
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. This is accomplished 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 of which uses the style sheet that
says the headings should be gray. At some point, the site's webmaster decides that
the headings should be white on a gray background. So she edits the style sheet to
say:
h1, h2, h3, h4, h5, h6 {color: white; background: gray;}
Then she 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 afont
tag, doesn't it?
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 import a single style sheet into several web pages. Now inject a set of pages
that share many of the same styles, but also include 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 could just place the special
styles into the pages that need them.
For example, on one page out of the 700, you might want headings to 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 can be changed easily and come together to give your pages
a professional look.
The power of the cascade is not confined to the author. Web surfers (or
readers
) can, in some browsers, create their own style sheets
(called
reader style sheets
,
obviously enough) that will cascade with the
author's styles as well as the styles used by the browser. Thus, a reader who is
colorblind could create a style that makes hyperlinks stand out:
a:link, a:visited {color: white; background: black;}
A reader style sheet can 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, and 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 is a wonderful tool for any author or reader.
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 I've mentioned, a lot of pages have used tables andfont
elements to achieve nifty visual effects.
Unfortunately, both of these methods create additional HTML markup that drives up the
file sizes. By grouping visual style information into central areas and representing
those rules using a fairly compact syntax, you can remove thefont
elements and other bits of the usual tag soup.
Thus, CSS can keep your load times low and your reader satisfaction high.
HTML, as I pointed out earlier, is a structural language, while CSS is its
complement: a stylistic language.
Recognizing this, the W3C, the body that debates
and approves standards for the Web, is beginning to remove stylistic elements from
HTML. The reasoning for this move is that style sheets can be used to create the
effects that certain HTML elements now provide, so who needs them?
Thus, the XHTML specification
has a
number of elements 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 elements are
,
,
,
,
, and
. With the advent of style sheets, none of these elements
are necessary. And there may be more elements deprecated as time goes by.
As if that weren't enough, there is the 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 provide any way to declare
style elements such as
or
. Instead, it is quite probable that XML
documents will rely on style sheets to determine their appearance. While the style
sheets used with XML may not be CSS, they will probably be whatever follows CSS and
very closely resemble it. Therefore, learning CSS now gives authors a big advantage
when the time comes to make the jump to an XML-based web.
So, to get started, it's very important to understand how CSS and document
structures relate to each other. It's possible to use CSS to affect document
presentation in a very profound way, but there are also limits to what you can do.
Let's start by exploring some basic terminology.