DekGenius.com
Previous Section  < Day Day Up >  Next Section

6.6 Text Shadows

CSS2 includes a property for adding drop shadows to text, but this property did not make it into CSS2.1 because no browser had implemented full support for it by the time CSS2.1 was finished. When you consider the effort necessary to make a web browser determine the outlines of text in an element and then compute one or more shadows, all of which would have to blend together without overlapping the text itself, the lack of drop shadows in the specification is perhaps understandable.

text-shadow


Values

none | [<color> || <length> <length> <length>? ,]* [<color> || <length> <length> <length>?] | inherit


Initial value

none


Applies to

all elements


Inherited

no


The obvious default is not to have a drop shadow for text. Otherwise, it's theoretically possible to define one or more shadows. Each shadow is defined by a color and three length values. The color sets the shadow's color, of course; so it's possible to define green, purple, or even white shadows.

The first two length values determine the offset distance of the shadow from the text, and the optional third length value defines the "blur radius" for the shadow. To define a green shadow offset five pixels to the right and half an em down from the text, with no blurring, you would write:

text-shadow: green 5px 0.5em;

Negative lengths cause the shadow to be offset to the left and upward from the original text.

The blur radius is defined as the distance from the shadow's outline to the edge of the blurring effect. A radius of two pixels would result in blurring that filled the space between the shadow's outline and the edge of the blurring. The exact blurring method is not defined, so different user agents might employ different effects. As an example, the following styles might be rendered something like Figure 6-31:

p.cl1 {color: black; text-shadow: silver 2px 2px 2px;}
p.cl2 {color: white; text-shadow: 0 0 4px black;}
p.cl3 {color: black; text-shadow: 1em 1em 5px gray, -1em -1em silver;}
Figure 6-31. Dropping shadows all over
figs/css2_0631.gif

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


6.6.1 Handling Whitespace

To wrap up this chapter, let's talk about the property white-space, which can greatly impact how text is actually displayed.

white-space


Values

normal | nowrap | pre | pre-wrap | pre-line | inherit


Initial value

normal


Applies to

all elements (CSS2.1); block-level elements (CSS1 and CSS2)


Inherited

no


Computed value

as specified


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

<p>This    paragraph   has     many
    spaces        in it.</p>

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. Any extra spaces and carriage returns are completely ignored by the browser.

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;}

<p>This    paragraph   has     many
    spaces        in it.</p>
Figure 6-32. Honoring the spaces in markup
figs/css2_0632.gif

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 property is nowrap, which prevents text from wrapping within a block-level element, except when you use a <br/> element. Using nowrap in CSS is much like setting a table cell not to wrap in HTML 4 with <td nowrap>, except the white-space value can be applied to any block-level element. The effects of the following markup are shown in Figure 6-33:

<p style="white-space: nowrap;">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 <br/>in the browser window.</p>
Figure 6-33. Suppressing line wrapping with the white-space property
figs/css2_0633.gif

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

td {white-space: nowrap;}

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

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

If an element is set to pre-wrap, then text within that element has whitespace sequences preserved but text lines that 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:

<p style="white-space: pre-wrap;">
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.
</p>
<p style="white-space: pre-line;">
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.
</p>
Figure 6-34. Two different ways to handle whitespace
figs/css2_0634.gif

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

Table 6-1. white-space properties

Value

Whitespace

Linefeeds

Auto line wrapping

normal

Collapsed

Ignored

Allowed

nowrap

Collapsed

Ignored

Prevented

pre

Preserved

Honored

Prevented

pre-wrap

Preserved

Honored

Allowed

6.6.2 Text Direction

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.

direction


Values:

ltr | rtl | inherit


Initial value

ltr


Applies to

all elements


Inherited

yes


Computed value

as specified


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 override. (See later in this section for a description of unicode-bidi.)

Before CSS3, CSS included no provisions in the specification for top-to-bottom languages. As of this writing, the CSS3 Text Module is a Candidate Recommendation, and it addresses this point with a new property called writing-mode.


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, encompassing all right-to-left languages not just Arabic and Hebrew, but it serves to illustrate the point. While CSS makes an attempt 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.

unicode-bidi


Values:

normal | embed | bidi-override | inherit


Initial value

normal


Applies to

all elements


Inherited

no


Computed value

as specified


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:


normal

The element does not open an additional level of embedding with respect to the bidirectional algorithm. For inline-level elements, implicit reordering works across element boundaries.


embed

If the element is inline-level, this value opens an additional level of embedding with respect to the bidirectional algorithm. The direction of this embedding level is given by the direction property. Inside the element, reordering is done implicitly. This corresponds to adding an LRE (U+202A; for direction: ltr) or an RLE (U+202B; for direction: rtl) at the start of the element and a PDF (U+202C) at the end of the element.


bidi-override

This creates an override for inline-level elements. For block-level elements, this creates an override for inline-level descendants not within another block. This means that, inside the element, reordering is strictly in sequence according to the direction property; the implicit part of the bidirectional algorithm is ignored. This corresponds to adding an LRO (U+202D; for direction: ltr) or RLO (U+202E; for direction: rtl) at the start of the element and a PDF (U+202C) at the end of the element.

    Previous Section  < Day Day Up >  Next Section