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

text-shadow

Figure 6-31. Dropping shadows all over

Figure 6-31
was produced using Photoshop,
since web browsers do not support
text-shadow
as
of this writing.

Now that we've covered a variety of ways to style the
text, let's talk about the property
white-space
,
which affects the user agent's handling of space, newline, and tab characters within
the document source.

Using this property, you can affect how a browser treats the whitespace between
words and lines
of text. To a certain extent, default XHTML handling
already does this: it collapses any whitespace down to a single space. So given the
following markup, the rendering in a web browser would show only one space between
each word and ignore the linefeed in the elements.

This    paragraph   has     many
spaces        in it.

You can explicitly set this default behavior with the following declaration:

p {white-space: normal;}

This rule tells the browser to do as browsers have always done: discard extra
whitespace. Given this value, linefeed characters (carriage returns) are converted
into spaces, and any sequence of more than one space in a row is converted to a
single space.

Should you set
white-space
to
pre
, however, the whitespace in an affected element is
treated as though the elements were XHTML
pre
elements; whitespace is
not
ignored, as shown in
Figure 6-32
:

p {white-space: pre;}
This    paragraph   has     many
spaces        in it.

Figure 6-32. Honoring the spaces in markup

With a
white-space
value of
pre
, the browser will pay attention to extra spaces and
even carriage returns. In this respect, and in this respect alone, any element can be
made to act like a
pre
element.

The opposite value is
nowrap
, which prevents
text from wrapping
within an
element, except wherever you use a
br
element.
Using
nowrap
in CSS is much like setting a table
cell not to wrap in HTML 4 with

,
except the
white-space
value can be applied to any
element. The effects of the following markup are shown in
Figure 6-33
:

This paragraph is not allowed to wrap,
which means that the only way to end a line is to insert a line-break
element.  If no such element is inserted, then the line will go forever,
forcing the user to scroll horizontally to read whatever can't be
initially displayed 
in the browser window.

Figure 6-33. Suppressing line wrapping with the white-space property

You can actually use
white-space
to replace the
nowrap
attribute on table cells:

td {white-space: nowrap;}





The contents of this cell are not wrapped.
Neither are the contents of this cell.
Nor this one, or any after it, or any other cell in this table.
CSS prevents any wrapping from happening.

CSS2.1 introduced the values
pre-wrap
and
pre-line
, which were absent in earlier versions
of CSS. The effect of these values is to allow authors to better control whitespace
handling.

If an element is set to
pre-wrap
, then text
within that element has whitespace sequences preserved, but text lines are wrapped
normally. With this value, line-breaks in the source and those that are generated are
also honored.
pre-line
is the opposite of
pre-wrap
and causes whitespace sequences to collapse as
in normal text but honors new lines. For example, consider the following markup,
which is illustrated in
Figure 6-34
:

This  paragraph      has  a  great   many   s p a c e s   within  its textual
content,   but their    preservation     will    not    prevent   line
wrapping or line breaking.


This  paragraph      has  a  great   many   s p a c e s   within  its textual
content,   but their collapse  will    not    prevent   line
wrapping or line breaking.

Figure 6-34. Two different ways to handle whitespace

Table 6-1
summarizes the behaviors of
white-space
properties.

If you're reading this book in English or any number of other languages, then
you're reading the text left to right and top to bottom, which is the flow direction
of English. Not every language runs this way, though. There are many right-to-left
languages such as Hebrew and Arabic, and CSS2 introduced a property to describe their
directionality.

The
direction
property affects the writing
direction of text in a block-level element, the direction of table column layout, the
direction in which content horizontally overflows its element box, and the position
of the last line of a fully justified element. For inline elements, direction applies
only if the property
unicode-bidi
is set to either
embed
or
bidi-override
. (See below for a description of
unicode-bidi
.)

Although
ltr
is the default, it is expected
that if a browser is displaying right-to-left text, the value will be changed to
rtl
. Thus, a browser might carry an internal
rule stating something like the following:

*:lang(ar), *:lang(he) {direction: rtl;}

The real rule would be longer and encompass all right-to-left languages, not just
Arabic and Hebrew, but it illustrates the point. While CSS attempts to address
writing direction, Unicode has a much more robust method for handling directionality.
With the property
unicode-bidi
, CSS authors can
take advantage of some of Unicode's capabilities.

Here we'll simply quote the value descriptions from the CSS2.1 specification,
which do a good job of capturing the essence of each value: