CSS: The Definitive Guide, 3rd Edition (2 page)

Read CSS: The Definitive Guide, 3rd Edition Online

Authors: Eric A. Meyer

Tags: #COMPUTERS / Web / Page Design

Chapter 1. CSS and Documents

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).

The Web's Fall from Grace

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.

What a Mess

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 the
font
element, to apply background colors and
images to documents and tables, to use
table
attributes (such as
cellspacing
), 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 and
font
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 uses
font
elements instead of heading elements like
h1
:

Page Title

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 elements instead of
font
elements, though, 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 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 and
    font
    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.

CSS to the Rescue

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.

Rich Styling

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 the
h1
into a table and load it up with a
ton of other elements like
font
and
U
. 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 the
h1
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.

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.

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 the
h2
headings in a document
to be purple. Using HTML, the way to do this would be to put a
font
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 40
font
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 those
font
elements. You're done, you're happy—and then you decide (or your
boss decides for you) that those
h2
headings
should really be dark green, not purple. Now you have to go back and fix every single
one of those
font
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 purple
font
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 styled
h1
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 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 2em 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 are even more
striking. Consider how long it would take to change the HTML markup for an
h1
and 12
h2
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.

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. 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 a
font
tag, doesn't it?

Cascading

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.

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 I've mentioned, a lot of pages have used tables and
font
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 the
font
elements 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 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.

Other books

Just Married...Again by Charlotte Hughes
Into the Night by Janelle Denison
Son of Our Blood by Barton, Kathi S.
SevenMarkPackAttackMobi by Weldon, Carys
GEN13 - Version 2.0 by Unknown Author
Some Kind of Magic by Cooper, R.
Last Chance to See by Douglas Adams, Mark Carwardine
Love & Lies: Marisol's Story by Ellen Wittlinger
Tokyo Love by Diana Jean

© ThomasStone 2015 - 2024    Contact for me [email protected]