] |
inherit
Initial: see individual properties
Applies to: all elements
Inherited: no
Percentages: N/A
Media: visual
The 'border' property is a shorthand property for setting the same
width, color, and style for all four borders of a box. Unlike the
shorthand 'margin' and 'padding' properties, the 'border' property
cannot set different values on the four borders. To do so, one or more
of the other border properties must be used.
For example, the first rule below is equivalent to the set of four
rules shown after it:
P { border: solid red }
P {
border-top: solid red;
border-right: solid red;
border-bottom: solid red;
border-left: solid red
}
Since, to some extent, the properties have overlapping functionality,
the order in which the rules are specified is important.
Consider this example:
BLOCKQUOTE {
border-color: red;
border-left: double;
color: black
}
In the above example, the color of the left border is black, while the
other borders are red. This is due to 'border-left' setting the width,
style, and color. Since the color value is not given by the
'border-left' property, it will be taken from the 'color' property.
The fact that the 'color' property is set after the 'border-left'
property is not relevant.
_________________________________________________________________
_________________________________________________________________
9 Visual rendering model
Contents
* 9.1 Introduction to the visual rendering model
+ 9.1.1 The viewport
+ 9.1.2 Containing blocks
* 9.2 Controlling box generation
+ 9.2.1 Block-level elements and block boxes
o Anonymous block boxes
+ 9.2.2 Inline-level elements and inline boxes
o Anonymous inline boxes
+ 9.2.3 Compact boxes
+ 9.2.4 Run-in boxes
+ 9.2.5 The 'display' property
* 9.3 Positioning schemes
+ 9.3.1 Choosing a positioning scheme: 'position' property
+ 9.3.2 Box offsets: 'top', 'right', 'bottom', 'left'
* 9.4 Normal flow
+ 9.4.1 Block formatting context
+ 9.4.2 Inline formatting context
+ 9.4.3 Relative positioning
* 9.5 Floats
+ 9.5.1 Positioning the float: the 'float' property
+ 9.5.2 Controlling flow next to floats: the 'clear' property
* 9.6 Absolute positioning
+ 9.6.1 Fixed positioning
* 9.7 Relationships between 'display', 'position', and 'float'
* 9.8 Comparison of normal flow, floats, and absolute positioning
+ 9.8.1 Normal flow
+ 9.8.2 Relative positioning
+ 9.8.3 Floating a box
+ 9.8.4 Absolute positioning
* 9.9 Layered presentation
+ 9.9.1 Specifying the stack level: the 'z-index' property
* 9.10 Text direction: the 'direction' and 'unicode-bidi' properties
+ 9.10.1 Interaction between inline flow and text direction
+ 9.10.2 Bidirectionality in HTML 4.0
9.1 Introduction to the visual rendering model
This chapter and the next describe the visual rendering model: how
user agents process the document tree for visual media.
In the visual rendering model, each element in the document tree
generates zero or more boxes according to the box model. The layout of
these boxes is governed by:
* box dimensions and type.
* positioning scheme (normal flow, float, and absolute positioning
models).
* relationships between elements in the document tree.
* external information (e.g., viewport size, intrinsic dimensions of
images, etc.).
The properties defined in this chapter and the next apply to both
continuous media and paged media. However, the meanings of the margin
properties vary when applied to paged media (see the page model for
details).
The visual rendering model does not specify all aspects of formatting
(e.g., it does not specify a letter-spacing algorithm). Conforming
user agents may behave differently for those formatting issues not
covered by this specification.
9.1.1 The viewport
User agents for continuous media generally offer users a viewport (a
window or other viewing area on the screen) through which users
consult a document. User agents may change the document's layout when
the viewport is resized (see the initial containing block). When the
viewport is smaller than the document's initial containing block, the
user agent should offer a scrolling mechanism. There is at most one
viewport per canvas, but user agents may offer users several views of
a document.
9.1.2 Containing blocks
In CSS2, all box positions are calculated with respect to the edges of
a rectangular box called a containing block. A box establishes
reference edges for its descendants and is itself positioned with
respect to its containing block. The phrase "a box's containing block"
means "the containing block in which the box lives", not the one it
generates.
Each box is positioned with respect to its containing block, but it is
not confined by this containing block (it may overflow)
The root of the document tree generates a box that serves as the
initial containing block for subsequent layout. If the 'width'
property for the root element has the value 'auto', the user agent
supplies an initial width (e.g., the user agent uses the current width
of the viewport). The initial containing block cannot be positioned or
floated (i.e., user agents ignore the 'position' 'float' properties
for the root element).
The details of how a containing block's dimensions are calculated are
described in the next chapter.
9.2 Controlling box generation
The following sections describe the types of boxes that may be
generated in CSS2. A box's type affects, in part, its behavior in the
visual rendering model. The 'display' property, described below,
specifies a box's type.
9.2.1 Block-level elements and block boxes
Block-level elements are those elements of the source document
language that are formatted visually as blocks (e.g., paragraphs).
Several values of the 'display' property make an element block-level:
'block', 'list-item', 'compact' and 'run-in' (part of the time; see
compact and run-in boxes), and 'table'.
Block-level elements generate a principal block box that contains
block boxes. The principal block box establishes the containing block
for descendant boxes and is also the box involved in any positioning
scheme. Sibling block boxes participate in a block formatting context.
Some block-level elements generate additional boxes outside of the
principal box: 'list-item' elements and those with markers. These
additional boxes follow the principal box when it is positioned.
Anonymous block boxes
In a document like this:
(and assuming the DIV and the P both have 'display: block'), the DIV
appears to have both inline content and block content. To make it
easier to define the formatting, we assume that there is an anonymous
block box around "Some text".
diagram showing the three boxes for the example above
Diagram showing the three boxes, of which one is anonymous, for the
example above
In other words: if a block box (such as that generated for the DIV
above) has another block box inside it (such as the P above), then we
force it to have only block boxes inside it, by wrapping any inline
boxes in an anonymous block box.
The properties of these anonymous boxes are inherited from the
enclosing non-anonymous box (in the example: the one for DIV).
Non-inherited properties have their initial value. For example, the
font of the anonymous box is inherited from the DIV, but the margins
will be 0.
9.2.2 Inline-level elements and inline boxes
Inline-level elements are those elements of the source document that
do not form new blocks of content; the content is distributed in lines
(e.g., emphasized pieces of text within a paragraph, inline images,
etc.). Several values of the 'display' property make an element
inline: 'inline', 'inline-table', 'compact' and 'run-in' (part of the
time; see compact and run-in boxes). Inline-level elements generate
inline boxes.
An inline box participates in an inline formatting context with its
siblings and children.
Anonymous inline boxes
In a document like this:
Some emphasized text
The P generates a block box, with several inline boxes inside it. The
box for "emphasized" is an inline box generated by an inline element
(EM), but the other boxes ("Some" and "text") are inline boxes
generated by a block-level element (P). The latter are called
anonymous inline boxes, because they don't have an associated
inline-level element.
Such anonymous inline boxes inherit inheritable properties from their
block parent box. Non-inherited properties have their initial value.
In the example, the color of the anonymous initial boxes is inherited
from the P, but the background is transparent.
If it is clear from the context which type of anonymous box is meant,
both anonymous inline boxes and anonymous block boxes are simply
called anonymous boxes in his specification.
There are more types of anonymous boxes in the table context.
9.2.3 Compact boxes
A compact box behaves as follows:
* If a block box (that does not float and is not absolutely
positioned) follows the compact box, the compact box is formatted
like a one-line inline box. The resulting box width is compared to
one of the side margins of the block box. The choice of left or
right margin is determined by the 'direction' specified for the
element producing the containing block for the compact box and
following box. If the inline box width is less than or equal to
the margin, the inline box is positioned in the margin as
described immediately below.
* Otherwise, the compact box behaves like a block box.
The compact box is positioned in the margin as follows: it is outside
(to the left or right) of the first line box of the block, but it
affects the calculation of that line box's height. The
'vertical-align' property of the compact box determines the vertical
position of the compact box relative to that line box. The horizontal
position of the compact box is always in the margin of the block box.
An element that cannot be rendered on one line cannot be placed in the
margin of the following block. For example, a 'compact' element in
HTML that contains a element will always be rendered as a block
box (assuming the default style for BR, which inserts a newline). For
placing multi-line texts in the margin, the 'float' property is often
more adequate.
The following example illustrates a compact box.
A compact box example
Short
Description goes here.
too long for the margin
Description goes here.
This example might be rendered as:
short Description goes here
too long for the margin
Description goes here
The 'text-align' property can be used to align the compact element
inside the margin: against the left edge of the margin ('left'),
against the right edge ('right'), or centered in the margin
('center'). The value 'justify' doesn't apply, and is handled as
either 'left' or 'right', depending on the 'direction' of the
block-level element in whose margin the compact element is rendered.
('left' if the direction is 'ltr', 'right' if it is 'rtl'.)
Please consult the section on generated content for information about
how compact boxes interact with generated content.
9.2.4 Run-in boxes
A run-in box behaves as follows:
* If a block box (that does not float and is not absolutely
positioned) follows the run-in box, the run-in box behaves like an
inline child of the block box.
* Otherwise, the run-in box behaves like a block box.
A 'run-in' box is useful for run-in headers, as in this example:
A run-in box example
A run-in heading.
And a paragraph of text that
follows it.
This example might be rendered as:
A run-in heading. And a
paragraph of text that
follows it.
The properties of the run-in element are inherited from its parent in
the source tree, not from the block box it visually becomes part of.
Please consult the section on generated content for information about
how run-in boxes interact with generated content.
9.2.5 The 'display' property
'display'
Value: inline | block | list-item | run-in | compact | marker
| table | inline-table | table-row-group | table-column-group |
table-header-group | table-footer-group | table-row |
table-cell | table-caption | none | inherit
Initial: inline
Applies to: all elements
Inherited: no
Percentages: N/A
Media: all
The values of this property have the following meanings:
block
This value causes an element to generate a principal block box.
inline
This value causes an element to generate one or more inline
boxes.
list-item
This value causes an element to generate a principal block box
and a list-item marker box. For example, in HTML, the LI
element will typically have this 'display' value. For
information about lists and examples of list formatting, please
consult the section on lists.
marker
This value declares generated content before or after a box to
be a marker. This value is only useful with the :before and
:after pseudo-elements, on other elements is interpreted as
'inline'. Please consult the section on markers for more
information.
none
This value causes an element to generate no boxes in the
rendering structure (i.e., the element has no effect on
layout). Descendant elements do not generate any boxes either;
this behavior cannot be overridden by setting the 'display'
property on the descendants.
Please note that a display of 'none' does not create an
invisible box; it creates no box at all. CSS includes
mechanisms that enable an element to generate boxes in the
rendering structure that affect formatting but are not visible
themselves. Please consult the section on visibility for
details.
run-in and compact
These values create either block or inline boxes, depending on
context. Properties apply to run-in and compact boxes based on
their final status (inline-level or block-level). For example,
the 'white-space' property only applies if the box behaves like
a block box.
table, inline-table, table-row-group, table-column-group,
table-header-group, table-footer-group, table-row, table-cell,
and table-caption
These values cause an element to behave like a table element
(subject to restrictions described in the chapter on tables).
Note that although the initial value of 'display' is 'inline', rules
in the user agent's default style sheet may override this value. See
the sample style sheet for HTML 4.0 in the appendix.
Here are some examples of the 'display' property:
P { display: block }
EM { display: inline }
LI { display: list-item }
IMG { display: none } /* Don't display images */
Conforming HTML user agents may ignore the 'display' property when
specified in author and user style sheets but must specify a value for
it in the default style sheet.
9.3 Positioning schemes
In CSS2, a box may be laid out according to three positioning schemes
1. Normal flow. In CSS2, normal flow includes block formatting of
block boxes, inline formatting of inline boxes, relative
positioning of block or inline boxes, and positioning of compact
and run-in boxes.
2. Floats. In the float model, a box is first positioned in the
normal flow, then taken out of the flow and shifted to the left or
right as far as possible. Content may flow along the side of a
float.
3. Absolute positioning. In the absolute positioning model, a box is
removed from the normal flow entirely (it has no impact on later
siblings) and assigned coordinates with respect to a containing
block.
9.3.1 Choosing a positioning scheme: 'position' property
The 'position' and 'float' properties determine which CSS2 positioning
algorithms are used to calculate the coordinates of a box.
'position'
Value: static | relative | absolute | fixed | inherit
Initial: static
Applies to: all elements (except generated content)
Inherited: no
Percentages: N/A
Media: visual
The values of this property have the following meanings:
static
The box is a normal box, positioned according to the normal
flow. The 'left' and 'top' properties do not apply. (The word
"static" may seem confusing--—
static than 'static'-—
expectation is that it will most often be used in scripts that
"animate" elements by modifying 'top', 'left', 'bottom', and/or
'right'.)
relative
The box coordinates are calculated according to the normal
flow, then the box is offset relative to its normal position.
When a box B is relatively positioned, the position of the
following box is calculated as though B were not offset.
absolute
The box coordinates (and possibly size) are assigned with the
'left' 'right', 'top', and 'bottom' properties. These
properties specify offsets with respect to the box's containing
block. Absolutely positioned boxes are taken out of the normal
flow. This means they have no impact on the layout of later
siblings. Also, though absolutely positioned boxes have
margins, they do not collapse with any other margins.
fixed
The box coordinates are calculated according to the 'absolute'
model, but in addition, the box is fixed with respect to some
reference. In the case of continuous media, the box is fixed
with respect to the viewport (and doesn't move when scrolled).
In the case of paged media, the box is fixed with respect to
the page, even if that page is seen through a viewport (in the
case of a print-preview, for example). Authors may wish to
specify 'fixed' in a media-dependent way. For instance, an
author may want a box to remain at the top of the viewport on
the screen, but not at the top of each printed page. The two
specifications may be separated by using an @media rule, as in:
@media screen {
H1#first { position: fixed }
}
@media print {
H1#first { position: static }
}
9.3.2 Box offsets: 'top', 'right', 'bottom', 'left'
The position of a relatively or absolutely (including fixed)
positioned box is established by four properties:
'top'
Value: | | auto | inherit
Initial: auto
Applies to: all elements
Inherited: no
Percentages: refer to height of containing block
Media: visual
This property specifies how far a box's top content edge is offset
below the top edge of the box's containing block.
'right'
Value: | | auto | inherit
Initial: auto
Applies to: all elements
Inherited: no
Percentages: refer to width of containing block
Media: visual
This property specifies how far a box's right content edge is offset
to the left of the right edge of the box's containing block.
'bottom'
Value: | | auto | inherit
Initial: auto
Applies to: all elements
Inherited: no
Percentages: refer to height of containing block
Media: visual
This property specifies how far a box's bottom content edge is offset
above the bottom of the box's containing block.
'left'
Value: | | auto | inherit
Initial: auto
Applies to: all elements
Inherited: no
Percentages: refer to width of containing block
Media: visual
This property specifies how far a box's left content edge is offset to
the right of the left edge of the box's containing block.
The values for the four properties have the following meanings:
The offset is a fixed distance from the reference edge.
The offset is a percentage of the containing block's width (for
'left' or 'right') or height (for 'top' and 'bottom').
auto
The value depends on which of the other properties are 'auto'
as well. See "Width of absolutely positioned boxes".
For absolutely positioned boxes, the offsets are with respect to the
box's containing block. For relatively positioned boxes, the offsets
are with respect to the outer edges of the box itself (i.e., the box
is normally positioned, then offset from that position according to
these properties).
9.4 Normal flow
Boxes in the normal flow belong to a formatting context, which may be
block or inline, but not both simultaneously. Block boxes participate
in a block formatting context. Inline boxes participate in an inline
formatting context.
9.4.1 Block formatting context
In a block formatting context, boxes are laid out one after the other,
vertically, beginning at the top of a containing block. The vertical
distance between two sibling boxes is determined by the 'margin'
properties. Vertical margins between adjacent block boxes in a block
formatting context collapse.
In a block formatting context, each box's left outer edge touches the
left edge of the containing block (for right-to-left formatting, right
edges touch).
For information about page breaks in paged media, please consult the
section on allowed page breaks.
9.4.2 Inline formatting context
In an inline formatting context, boxes are laid out horizontally, one
after the other, beginning at the top of a containing block.
Horizontal margins, borders, and padding are respected between these
boxes. They may be aligned vertically in different ways: their bottoms
or tops may be aligned, or the baselines of text within them may be
aligned. The rectangular area that contains the boxes that form a line
is called a line box. The margin between the first inline box in a
line box and the near line box edge is respected; the same holds for
the last inline box and the opposite line box edge.
The width of a line box is determined by a containing block. The
height of a line box is determined by the rules given in the section
on line height calculations. A line box is always tall enough for all
of the boxes it contains. However, it may be taller than the tallest
box it contains (if, for example, boxes are aligned so that baselines
line up). When the height of a box B is less than the height of the
line box containing it, the vertical alignment of B within the line
box is determined by the 'vertical-align' property.
When several inline boxes cannot fit within a single line box, they
are distributed among two or more vertically-stacked line boxes. Thus,
a paragraph is a vertical stack of line boxes. Line boxes are stacked
with no vertical separation and they never overlap.
In left-to-right formatting, the left edge of a line box generally
touches the left edge of its containing block (right edges touch in
right-to-left formatting). However, floating boxes may come between
the containing block edge and the line box edge. Thus, although line
boxes in the same inline formatting context generally have the same
width (that of the containing block), they may vary in width if
available horizontal space is reduced due to floats. Line boxes in the
same inline formatting context generally vary in height (e.g., one
line might contain a tall image while the others contain only text).
When the total width of the boxes on a line is less than the width of
the line box containing them, their horizontal distribution within the
line box is determined by the 'text-align' property. If that property
has the value 'justify', the user agent may stretch the inline boxes
as well.
Since an inline box may not exceed the width of a line box, long
inline boxes are split into several boxes and these boxes distributed
across several line boxes. When an inline box is split, margins,
borders, and padding have no visual effect where the split occurs.
Rendering of margins, borders, and padding may not be fully defined if
the split occurs within a bidirectional embedding.
Inline boxes may also be split into several boxes within the same line
box due to bidirectional text processing.
Here is an example of inline box construction. The following paragraph
(created by the HTML block-level element P) contains anonymous text
interspersed with the elements EM and STRONG:
Several emphasized words appear
in this sentence, dear.
The P element generates a block box that contains five inline boxes,
three of which are anonymous:
* Anonymous: "Several"
* EM: "emphasized words"
* Anonymous: "appear"
* STRONG: "in this"
* Anonymous: "sentence, dear."
To format the paragraph, the user agent flows the five boxes into line
boxes. Since the parent box in normal flow acts as the containing
block for an inline box, the width of the P box determines the width
of these line boxes. If the width of P is sufficient, all the inline
boxes will fit into a single line box:
Several emphasized words appear in this sentence, dear.
If the boxes do not fit within a single line box, they will be split
up and distributed across several line boxes. The previous paragraph
might be split as follows:
Several emphasized words appear
in this sentence, dear.
or like this:
Several emphasized
words appear in this
sentence, dear.
In the previous example, the EM box was split into two EM boxes (call
them "split1" and "split2"). Margins, borders, padding, or text
decorations have no visible effect after split1 or before split2.
Consider the following example:
Example of inline flow on several lines
Several emphasized words appear here.
Depending on the width of the P, the boxes may be distributed as
follows:
Image illustrating the effect of line breaking on the display of
margins, borders, and padding.
* The margin is inserted before "emphasized" and after "words".
* The padding is inserted before, above, and below "emphasized" and
after, above, and below "words". A dashed border is rendered on
three sides in each case.
Note that with a small line height, the padding and borders around
text in different lines may overlap.
9.4.3 Relative positioning
Once a box has been assigned a position according to the normal flow,
it may be shifted relative to this position. This is called relative
positioning. Offsetting a box in this way has no effect on the
following box: it is positioned as if the preceding box were not
offset and it is not repositioned after the offset is applied. This
implies that relative positioning may cause boxes to overlap.
Relatively positioned boxes keep their normal flow size, including
line breaks and the space originally reserved for them. A relatively
positioned box establishes a new containing block for descendant
boxes.
A relatively positioned box is generated when the 'position' property
for an element has the value 'relative'. The offset is specified by
the 'top', 'bottom', 'left', and 'right' properties.
Dynamic movement of relatively positioned boxes can produce animation
effects in scripting environments (see also the 'visibility'
property). Relative positioning may also be used as a general form of
superscripting and subscripting except that line height is not
automatically adjusted to take the positioning into consideration. See
the description of line height calculations for more information.
Examples of relative positioning are provided in the section comparing
normal, relative, floating, and absolute positioning.
9.5 Floats
A float is a box that is shifted to the left or right on the current
line. The most interesting characteristic of a floated box is that
content may flow along its side (or be prohibited from doing so by the
'clear' property). Content flows down the right side of a left-floated
box and down the left side of a right-floated box. The following is an
introduction to float positioning and content flow; the exact rules
governing float behavior are given in the description of the 'float'
property.
A floated box must have an explicit width (assigned via the 'width'
property, or its intrinsic width in the case of replaced elements). A
floated box becomes a block box that is shifted to the left or right
until its outer edge touches the containing block edge or the outer
edge of another float. The top of the floated box is aligned with the
top of the current line box (or bottom of the preceding block box if
no line box exists). If there isn't enough horizontal room on the
current line for the float, it is shifted downward, line by line,
until a line has room for it.
Since a float is not in the flow, non-positioned block boxes created
before and after the float box flow vertically as if the float didn't
exist. However, line boxes created next to the float are shortened to
make room for the float. Any content in the current line before a
floated box is reflowed in the first available line on the other side
of the float.
Several floats may be adjacent, and this model also applies to
adjacent floats in the same line.
The following rule floats all IMG boxes with class="icon" to the left
(and sets the left margin to '0'):
IMG.icon {
float: left;
margin-left: 0;
}
Consider the following HTML source and style sheet:
Some sample text that has no other...
The IMG box is floated to the left. The content that follows is
rendered to the right of the float, starting on the same line as the
float. The line boxes to the right of the float are shortened due to
the float's presence, but resume their "normal" width (that of the
containing block established by the P element) after the float. This
document might be formatted as:
Image illustrating how floating boxes interact with margins.
Rendering would have been exactly the same if the document had been:
Some sample text
that has no other...
because the content to the left of the float is displaced by the float
and reflowed down its right side.
The margins of floating boxes never collapse with margins of adjacent
boxes. Thus, in the previous example, vertical margins do not collapse
between the P box and the floated IMG box.
A float can overlap other boxes in the normal flow (e.g., when a
normal flow box next to a float has negative margins). When an inline
box overlaps with a float, it is rendered in front of the float. When
a block box overlaps, the background and borders of the block box are
"clipped" by the non-transparent parts of the float, but the content
is rendered in front of the float.
Here is another illustration, showing what happens when a float
overlaps borders of elements in the normal flow.
Image showing a floating image that overlaps the borders of two
paragraphs: the borders are interrupted by the image.
The floating image is larger than the block that it is a child of, so
it interrupts the border of the block, and also the border of the next
block. Borders are "clipped" by floats".
The following example illustrates the use of the 'clear' property to
prevent content from flowing next to a float.
This style rule means that no H1 element may have a floating element
to its left; this means that H1 elements will be positioned below any
left floating box.
H1 { clear: left }
Here is an example illustrating the effect of 'clear: left' on two
paragraphs. Assuming a rule such as this:
P {clear: left }
a rendering might look like this:
Image showing a floating image and the effect of 'clear: left' on the
two paragraphs.
Both paragraphs have set 'clear: left', which causes the second
paragraph to be "pushed down" to a position below the float.
9.5.1 Positioning the float: the 'float' property
'float'
Value: left | right | none | inherit
Initial: none
Applies to: elements that are not positioned absolutely
Inherited: no
Percentages: N/A
Media: visual
This property specifies whether a box should float to the left, right,
or not at all. It may be set for elements that generate boxes that are
not positioned absolutely (i.e., not 'absolute' or 'fixed'). The
values of this property have the following meanings:
left
The element generates a block box that is floated to the left.
Content flows on the right side of the box, starting at the top
(subject to the 'clear' property). The 'display' is ignored,
unless it has the value 'none'.
right
Same as 'left', but content flows on the left side of the box,
starting at the top.
none
Has no effect on the generated box.
Here are the precise rules that govern the behavior of floats:
1. The left outer edge of a left-floating box may not be to the left
of the left edge of its containing block. An analogous rule holds
for right-floating elements.
2. If the current box is left-floating, and there are any left
floating boxes generated by elements earlier in the source
document, then for each such earlier box, either the left outer
edge of the current box must be to the right of the right outer
edge of the earlier box, or its top must be lower than the bottom
of the earlier box. Analogous rules hold for right-floating boxes.
3. The right outer edge of a left-floating box may not be to the
right of the left outer edge of any right-floating box that is to
the right of it. Analogous rules hold for right-floating elements.
4. A floating box's outer top may not be higher than the top of its
containing block.
5. The outer top of a floating box may not be higher than the outer
top of any block or floated box generated by an element earlier in
the source document.
6. The outer top of an element's floating box may not be higher than
the top of any line-box containing a box generated by an element
earlier in the source document.
7. A floating box must be placed as high as possible.
8. A left-floating box must be put as far to the left as possible, a
right-floating box as far to the right as possible. A higher
position is preferred over one that is further to the left/right.
9.5.2 Controlling flow next to floats: the 'clear' property
'clear'
Value: none | left | right | both | inherit
Initial: none
Applies to: block-level elements
Inherited: no
Percentages: N/A
Media: visual
This property indicates which sides of an element's box(es) may not be
adjacent to an earlier floating box. (It may be that the element
itself has floating descendants; the 'clear' property has no effect on
those.)
This property may only be specified for block-level elements
(including floats). For compact and run-in boxes, this property
applies to the final block box to which the compact or run-in box
belongs.
Values have the following meanings when applied to non-floating block
boxes:
left
The top margin of the generated box is increased enough that
the top border edge is below the bottom outer edge of any left
floating boxes that resulted from elements earlier in the
source document.
right
Same as left, but with respect to right floating boxes.
both
The generated box is moved below all floating boxes of earlier
elements in the source document..
none
No constraint on the box's position with respect to floats.
When the property is set on floating elements, it results in a
modification of the rules for positioning the float. An extra
constraint (#9) is added:
* The top outer edge of the float must be below the bottom outer
edge of all earlier left floating boxes (in the case of 'clear:
left'), or all earlier right floating boxes (in the case of
'clear: right'), or both ('clear: both').
9.6 Absolute positioning
In the absolute positioning model, a box is assigned explicit
coordinates with respect to its containing block. It is removed from
the normal flow entirely (it has no impact on later siblings). Like
other boxes, an absolutely positioned box establishes a new containing
block for descendant boxes. However, the contents of an absolutely
positioned element do not flow around any other boxes. They may or may
not obscure the contents of another box, depending on the stack levels
of the overlapping boxes.
9.6.1 Fixed positioning
Fixed positioning is a variant of absolute positioning. The only
difference is that for a fixed positioned box, the containing block is
established by the viewport. For continuous media, fixed boxes do not
move when the document is scrolled. In this respect, they are similar
to fixed background images. For paged media, boxes with fixed
positions are repeated on every page. This is useful for placing, for
instance, a signature at the bottom of each page.
Authors may use fixed positioning to create frame-like presentations.
Consider the following frame layout:
Image illustrating a frame-like layout with position='fixed'.
This might be achieved with the following HTML document and style
rules:
A frame document with CSS2
...
9.7 Relationships between 'display', 'position', and 'float'
When specified for the same elements, the three properties that affect
box generation and layout -- 'display', 'position', and 'float' --
interact according to the following precedences (highest to lowest):
1. If 'display' has the value 'none', user agents must ignore
'position' and 'float'. In this case, the element generates no
box.
2. Otherwise, if 'position' has the value 'absolute' or 'fixed', the
generated box will be non-floating and block. The position of the
box will be determined by the 'top', 'right', 'bottom' and 'left'
properties and the box's containing block.
3. Otherwise, if 'float' has a value other than 'none', the generated
box is a block box and is floated.
4. Otherwise, the remaining 'display' properties apply as specified.
Note. CSS2 does not specify layout behavior when values for these
properties are changed by scripts. For example, what happens when an
element having 'width: auto' is repositioned? Do the contents reflow,
or do they maintain their original formatting? The answer is outside
the scope of this document, and such behavior is likely to differ in
initial implementations of CSS2.
9.8 Comparison of normal flow, floats, and absolute positioning
To illustrate the relationship between normal flow, relative
positioning, floats, and absolute positioning, we provide a series of
examples based on the following HTML fragment:
Comparison of positioning schemes
Beginning of body contents.
Start of outer contents.
Inner contents.
End of outer contents.
End of body contents.
The final positions of boxes generated by the outer and inner elements
vary in each example. In each illustration, the numbers to the left of
the illustration indicate the normal flow position of the
double-spaced (for clarity) lines. (Note: the illustrations use
different horizontal and vertical scales.)
9.8.1 Normal flow
Consider the following CSS declarations for outer and inner that don't
alter the normal flow of boxes:
#outer { color: red }
#inner { color: blue }
This results in something like the following:
Image illustrating the normal flow of text between parent and sibling
boxes.
9.8.2 Relative positioning
To see the effect of relative positioning, consider the following CSS
rules:
BODY { line-height: 200% }
#outer { position: relative; top: -12px; color: red }
#inner { position: relative; top: 12px; color: blue }
First, the outer text is flowed into its normal flow position and
dimensions at the end of line 1. Then, the inline boxes containing the
text (distributed over three lines) are shifted as a unit upwards by
12px.
The contents of inner, as a child of outer, would normally flow
immediately after the words "of outer contents" (on line 1.5).
However, the inner contents are themselves offset relative to the
outer contents by 12px downwards, back to their original position on
line 2.
Note that the content following outer is not affected by the relative
positioning of outer.
Image illustrating the effects of relative positioning on a box's
content.
Note also that if the relative positioning of outer were -24px, the
text of outer and the body text would have overlapped.
9.8.3 Floating a box
Now consider the effect of floating the inner element's text to the
right by means of the following rules:
#outer { color: red }
#inner { float: right; width: 130px; text-align: top; color: blue }
First, the inner box (whose width has been set explicitly) is floated
to the right margin. Then, the text of the outer element that follows
the inner element text flows in the space vacated by the inner box.
This flow respects the new right margin established by the left border
of the inner box.
Image illustrating the effects of floating a box.
To show the effect of the 'clear' property, we add a sibling element
to the example:
Comparison of positioning schemes II
Beginning of body contents.
Start of outer contents.
Inner contents.
Sibling contents.
End of outer contents.
End of body contents.
The following rules:
#inner { float: right; width: 130px;
text-align: top; color: blue }
#sibling { color: red }
cause the inner box to float to the right and the text of the sibling
element to flow in the vacated space:
Image illustrating the effects of floating a box without setting the
clear property to control the flow of text around the box.
However, if the 'clear' property on the sibling element is set to
'right' (i.e., the generated sibling box will not accept being
positioned next to floating boxes to its right), the sibling box is
moved below the float:
#inner { float: right; width: 130px;
text-align: top; color: blue }
#sibling { clear: right; color: red }
Image illustrating the effects of floating an element with setting the
clear property to control the flow of text around the element.
9.8.4 Absolute positioning
Finally, we consider the effect of absolute positioning. Consider the
following CSS declarations for outer and inner:
#outer {
position: absolute;
top: 200px;
left: 200px;
width: 200px;
color: red;
}
#inner { color: blue }
which cause the top of the outer box to be positioned with respect to
the containing block (which we suppose is established by the initial
containing block). The top side of the outer box is 200px from the top
of the containing block and the left side is 200px from the left side.
The child box of outer is flowed normally with respect to its parent.
Image illustrating the effects of absolutely positioning a box.
Note that because outer has been absolutely positioned, it establishes
a new containing block for descendant boxes.
The following example shows an absolutely positioned box that is a
child of a relatively positioned box. Although the parent outer box is
not actually offset, setting its 'position' property to 'relative'
causes its box to serve as the containing block for any descendant
boxes. Since the outer box is an inline box that is split across
several lines, only the first box (whose upper left-hand corner is
designated by a "@" in the illustration below) establishes the
containing block for the descendants.
#outer {
position: relative;
color: red
}
#inner {
position: absolute;
top: 200px;
left: -100px;
height: 130px;
width: 130px;
color: blue;
}
This results in something like the following:
Image illustrating the effects of absolutely positioning a box with
respect to a containing block.
The following rules don't establish a new positioning context for
inner:
#outer { color: red }
#inner {
position: absolute;
top: 200px;
left: -100px;
height: 130px;
width: 130px;
color: blue;
}
but cause the inner box to be positioned with respect to the
containing block (which we assume here is initial containing block).
Image illustrating the effects of absolutely positioning a box with
respect to a coordinate system established by a normally positioned
parent.
Relative and absolute positioning may be used to implement change
bars, as shown in the following example. We use a value of 'auto' for
the 'top' property, which results in the box being placed at the
"current" location, just as if the box were being flowed into that
space. The following HTML text:
I used two red hyphens to serve as a change bar. They
will "float" to the left of the line containing THIS
--
word.
might result in something like:
Image illustrating the use of floats to create a changebar effect.
9.9 Layered presentation
In the following sections, the expression "in front of" means closer
to the user as the user faces the screen.
In CSS2, each box has a position in three dimensions. In addition to
their horizontal and vertical positions, boxes lie along a "z-axis"
and are rendered one on top of the other. Z-axis positions are
particularly relevant when boxes overlap visually. This section
discusses how boxes may be positioned along the z-axis.
Each box belongs to one stacking context. Each box in a given stacking
context has an integer stack level, which is its position on the
z-axis relative to other boxes in the same stacking context. Boxes
with greater stack levels are always rendered in front of boxes with
lower stack levels. Boxes may have negative stack levels. Boxes with
the same stack level in a stacking context are stacked bottom-to-top
according to document tree order.
The root element creates a root stacking context, but other elements
may establish local stacking contexts. Stacking contexts are
inherited. A local stacking context is atomic; boxes in other stacking
contexts may not come between any of its boxes.
An element that establishes a local stacking context generates a box
that has two stack levels: one for the stacking context it creates
(always '0') and one for the stacking context to which it belongs
(given by the 'z-index' property).
An element's box has the same stack level as its parent's box unless
given a different stack level with the 'z-index' property.
9.9.1 Specifying the stack level: the 'z-index' property
'z-index'
Value: auto | | inherit
Initial: auto
Applies to: elements that generate absolutely and relatively
positioned boxes
Inherited: no
Percentages: N/A
Media: visual
For an absolutely or relatively positioned box, the 'z-index' property
specifies:
1. The stack level of the box in the current stacking context.
2. Whether the box establishes a local stacking context.
Values have the following meanings:
This integer is the stack level of the generated box in the
current stacking context. The box also establishes a local
stacking context in which its stack level is '0'.
auto
The stack level of the generated box in the current stacking
context is the same as its parent's box. The box does not
establish a new local stacking context.
In the following example, the stack levels of the boxes (named with
their "id" attributes) are: "text2"=0, "image"=1, "text3"=2, and
"text1"=3. The "text2" stack level is inherited from the root box. The
others are specified with the 'z-index' property.
Z-order positioning
This text will overlay the butterfly image.
This text will be beneath everything.
This text will underlay text1, but overlay the butterfly image
This example demonstrates the notion of transparency. The default
behavior of a box is to allow boxes behind it to be visible through
transparent areas in its content. In the example, each box
transparently overlays the boxes below it. This behavior can be
overridden by using one of the existing background properties.
9.10 Text direction: the 'direction' and 'unicode-bidi' properties
The characters in certain scripts are written from right to left. In
some languages, in particular those written with the Arabic or Hebrew
script, and in some mixed-language contexts, text in a single
(visually displayed) block can therefore appear with mixed
directionality. This phenomenon is called bidirectionality, or "bidi"
for short. For an introduction to bidirectionality issues, please
consult the HTML 4.0 specification ([HTML40], section 8.2).
The Unicode ([UNICODE]) specification assigns directionality to
characters and defines a complex algorithm for determining the proper
directionality of text. The 'direction' and 'unicode-bidi' properties
allow authors to specify how the elements and attributes of a document
language correspond to units of the Unicode bidi algorithm.
Because the directionality of a text depends on the structure and
semantics of the document language, these properties should in most
cases be used only by designers of document type descriptions (DTDs),
or authors of special documents. A typical exception would be to
override bidi behavior in a user agent if that user agent
transliterates Yiddish (usually written with Hebrew letters) to Latin
letters at the user's request.
If a document contains right-to-left characters, and if the user agent
displays these characters (with appropriate glyphs, not arbitrary
substitutes such as a question mark, a hex code, a black box, etc.),
the user agent must apply the bidirectional algorithm. This seemingly
one-sided requirement reflects the fact that, although not every
Hebrew or Arabic document contains mixed-directionality text, such
documents are much more likely to contain left-to-right text (e.g.,
numbers, text from other languages) than are documents written in
left-to-right languages.
Conforming HTML user agents may ignore the 'direction' and
'unicode-bidi' properties in author and user style sheets but must
behave as if they used the style sheet fragment given below.
'direction'
Value: ltr | rtl | inherit
Initial: ltr
Applies to: all elements, but see prose
Inherited: yes
Percentages: N/A
Media: visual
This property specifies the direction of inline box flow, embedded
text direction (see 'unicode-bidi'), table column layout, and content
overflow.
Values for this property have the following meanings:
ltr
Left-to-right direction.
rtl
Right-to-left direction.
'unicode-bidi'
Value: normal | embed | bidi-override | inherit
Initial: normal
Applies to: all elements, but see prose
Inherited: no
Percentages: N/A
Media: visual
The writing direction of text within an inline box depends on two
factors:
1. The directionality of the characters, as specified in the Unicode
specification ([UNICODE]).
2. The value of the 'unicode-bidi' property (in conjunction with the
value of the 'direction' property).
User agents following the bidirectional algorithm will display
characters in the correct writing direction automatically, except when
elements with reversed writing direction are embedded more than one
level deep. In such cases, authors must assist the user agent by
signaling that an element opens a new level of embedding with respect
to the bidirectional algorithm.
Thus, values for 'unicode-bidi' have the following meanings:
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
The element 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.
bidi-override
Like 'embed', the element opens an additional level of
embedding with respect to the bidirectional algorithm and the
direction of this embedding level is given by the 'direction'
property. However, inside the element, reordering is strictly
in sequence according to the 'direction' property; this value
overrides the implicit bidirectional algorithm.
For the 'direction' property to have any effect on inline-level
elements, the 'unicode-bidi' property must have as value either
'embed' or 'override'.
If a default style sheet specifies values for 'unicode-bidi', authors
and users should not specify rules to override them.
The following example shows an XML document with bidirectional text.
It illustrates an important design principle: DTD designers should
take bidi into account both in the language proper (elements and
attributes) and in any accompanying style sheets. The style sheets
should be designed so that bidi rules are separate from other style
rules. The bidi rules should not be overridden by other style sheets
so that the document language's or DTD's bidi behavior is preserved.
In this example, lowercase letters stand for inherently left-to-right
characters and uppercase letters represent inherently right-to-left
characters:
HEBREW1 HEBREW2 english3 HEBREW4 HEBREW5
HEBREW6 HEBREW7 HEBREW8
english9 english10 english11 HEBREW12 HEBREW13
english14 english15 english16
english17 HEBREW18 english19 HEBREW20
Since this is XML, the style sheet is responsible for setting the
writing direction. This is the style sheet:
/* Rules for bidi */
HEBREW, HE-QUO {direction: rtl; unicode-bidi: embed}
ENGLISH {direction: ltr; unicode-bidi: embed}
/* Rules for presentation */
HEBREW, ENGLISH, PAR {display: block}
EMPH {font-weight: bold}
The HEBREW element is a block with a right-to-left base direction, the
ENGLISH element is a block with a left-to-right base direction. The
PARs are blocks that inherit the base direction from their parents.
Thus, the first two PARs are read starting at the top right, the final
three are read starting at the top left.
The EMPH element is inline-level, and since its value for
'unicode-bidi' is 'normal' (the initial value), it has no effect on
the ordering of the text. The HE-QUO element, on the other hand,
creates an embedding.
The rendering of this text might look like this if the line length is
long:
5WERBEH 4WERBEH english3 2WERBEH 1WERBEH
8WERBEH 7WERBEH 6WERBEH
english9 english10 english11 13WERBEH 12WERBEH
english14 english15 english16
english17 20WERBEH english19 18WERBEH
Note that the HE-QUO embedding causes HEBREW18 to be to the right of
english19.
If lines have to be broken, it might be more like this:
2WERBEH 1WERBEH
-EH 4WERBEH english3
5WERB
-EH 7WERBEH 6WERBEH
8WERB
english9 english10 en-
glish11 12WERBEH
13WERBEH
english14 english15
english16
english17 18WERBEH
20WERBEH english19
Because HEBREW18 must be read before english19, it is on the line
above english19. Just breaking the long line from the earlier
rendering would not have worked. Note also that the first syllable
from english19 might have fit on the previous line, but hyphenation of
left-to-right words in a right-to-left context, and vice versa, is
usually suppressed to avoid having to display a hyphen in the middle
of a line.
Note that the default style sheet "states" that the HEBREW, HE-QUO,
and ENGLISH elements all create embeddings. This bidi behavior should
be preserved even if a user decides to change 'display: inline' for
these elements. The rules that specify 'unicode-bidi: embed' achieve
this as long as they are not overridden by user rules.
9.10.1 Interaction between inline flow and text direction
The 'direction' property determines the direction of several types of
flow:
1. When set for a block-level element, it specifies the base writing
direction of inline text generated by the element. It also
determines the position of an incomplete last line in a block in
case of 'text-align: justify'.
2. When set for an inline-level element, in coordination with a value
of 'embed' or 'bidi-override' for the 'unicode-bidi' property, it
specifies an additional embedding level.
3. When set for a table element, it specifies the direction of table
column layout. Note. The 'direction', when specified for table
column elements, is not inherited by cells in the column since
columns don't exist in the document tree. Thus, CSS cannot easily
capture the "dir" attribute inheritance rules described in
[HTML40], section 11.3.2.1.
4. It specifies the direction of horizontal overflow.
In order to ensure the proper application of the bidirectional
algorithm, inline boxes (including anonymous inline boxes) must be
constructed, split up if necessary, and flowed so that the final order
of the characters on each line conforms to the Unicode bidirectional
algorithm. This means that left-to-right character sequences and
right-to-left character sequences can occur within an element's
content, but inline boxes are constructed so that flow remains in one
direction. Non-textual entities such as images are treated as neutral
characters, unless their 'unicode-bidi' property has a value other
than 'normal', in which case they are treated as strong characters in
the 'direction' specified for the element.
For instance, suppose that in the middle of a paragraph of Hebrew
(right-to-left) text, we embed an English quotation:
WERBEH WERBEH WERBEH WERBEH WERBEH
WERBEH WERBEH WERBEH WERBEH WERBEH
WERBEH WERBEH WERBEH English
quote here WERBEH WERBEH>
The right-to-left flow of Hebrew text stops at the asterisk (*) in the
following diagram:
WERBEH WERBEH WERBEH WERBEH WERBEH
WERBEH WERBEH WERBEH WERBEH WERBEH
*WERBEH WERBEH WERBEH
While inline flow continues right-to-left after the asterisk, the
English text is laid out left-to-right. Thus, successive letters will
fill in the available space as follows:
E *WERBEH WERBEH WERBEH
En *WERBEH WERBEH WERBEH
Eng *WERBEH WERBEH WERBEH
Engl *WERBEH WERBEH WERBEH
Engli *WERBEH WERBEH WERBEH
Englis *WERBEH WERBEH WERBEH
Etc., onto the following line:
English quote *WERBEH WERBEH WERBEH
h
English quote *WERBEH WERBEH WERBEH
he
English quote *WERBEH WERBEH WERBEH
her
English quote *WERBEH WERBEH WERBEH
here
Hebrew text continues to flow right-to-left at the end of the English
text.
9.10.2 Bidirectionality in HTML 4.0
In order to preserve the expected behavior of HTML 4.0 elements, their
bidirectionality must be preserved however they are rendered. For
example, people expect paragraphs to behave like a block with respect
to bidirectionality, so even if a paragraph is displayed as an
'inline' element, it must introduce a new level of bidi embedding.
The following rules capture the remaining bidi semantics of HTML 4.0:
BDO[DIR="ltr"] { direction: ltr; unicode-bidi: bidi-override }
BDO[DIR="rtl"] { direction: rtl; unicode-bidi: bidi-override }
*[DIR="ltr"] { direction: ltr; unicode-bidi: embed }
*[DIR="rtl"] { direction: rtl; unicode-bidi: embed }
/* Block-level elements */
ADDRESS, BLOCKQUOTE, BODY, DD, DIV, DL, DT, FIELDSET,
FORM, FRAME, FRAMESET, H1, H2, H3, H4, H5, H6, IFRAME,
NOSCRIPT, NOFRAMES, OBJECT, OL, P, UL, APPLET, CENTER,
DIR, HR, MENU, PRE, LI, TABLE, TR, THEAD, TBODY, TFOOT,
COL, COLGROUP, TD, TH, CAPTION
{ unicode-bidi: embed }
_________________________________________________________________
_________________________________________________________________
10 Visual rendering model details
Contents
* 10.1 Details of containing block calculation
* 10.2 Calculation of box and line box widths
* 10.3 Box width calculations
+ 10.3.1 Content width: the 'width' property
+ 10.3.2 Width of boxes in the normal flow and floated boxes
o Determining the content width
o Computing margin widths
+ 10.3.3 Width of absolutely positioned boxes
+ 10.3.4 Minimum and maximum widths: 'min-width' and
'max-width'
* 10.4 Box height calculations
+ 10.4.1 Content height: the 'height' property
+ 10.4.2 Determining the content height
+ 10.4.3 Height of absolutely positioned boxes
+ 10.4.4 Minimum and maximum heights: 'min-height' and
'max-height'
* 10.5 Line height calculations: the 'line-height' and
'vertical-align' properties
+ 10.5.1 Leading and half-leading
10.1 Details of containing block calculation
The containing block for a box other than the root box is determined
as follows:
* If the value of the 'position' property for the parent element is
anything but 'static' then the containing block is established by
the parent box.
* Otherwise, if the value of the 'display' property for the parent
element is anything but 'inline' then the containing block is
established by the parent box.
* Otherwise, the containing block is the parent's containing block.
When a containing block is established by a block box, it has the same
width, height, and position as the box's padding edge. The edges are
called the top, bottom, left, and right of the containing block.
When a containing block is established by an inline-level element, it
has the same width, height, and position as the padding edge of the
first (in the source tree) inline box generated by the inline-level
element.
Relatively positioned inline boxes must be considered specially since
(1) the rendered content of an inline-level element may not be
rectangular in shape but (2) a relatively positioned box establishes a
new containing block and containing blocks must be rectangular. The
reference edges for descendants are the following:
* For left-to-right scripts, the left and top edges are those of the
first inline box. The bottom and right edges are those of the last
inline box.
* For right-to-left scripts, the right and top edges are those of
the first inline box. The bottom and left edges are those of the
last inline box.
10.2 Calculation of box and line box widths
Box and line box widths and heights may be established in one of
several ways:
Width and height properties set explicitly
If 'width' or 'height' is set explicitly (i.e., not 'auto'),
the box will have the specified width or height, except in
tables, where a 'width' or 'height' is interpreted as a minimum
size, or even ignored, depending on the table layout algorithm.
The 'width' and 'height' properties do not apply to
non-replaced inline elements.
Block box widths are calculated top-down
The width of a block box is given by the width of its
containing block minus the box's margins, borders, and padding.
Inline box widths are calculated bottom-up
The width of an inline box is given by its rendered content.
Block box heights are calculated bottom-up
Block level boxes grow to the size of the boxes they contain
(unless the 'height' property is set). Please consult the
section on box height calculations for details.
Inline box heights are given by the 'line-height' property
Please consult the section on box height calculations for
details.
Line heights depend on inline box heights and alignment
Please consult the section on line height calculations for
details.
Intrinsic dimension of replaced content
The rendered content of a replaced element may have "intrinsic
dimensions" that user agents use as the computed content width
and height (e.g., the unscaled width and height of an included
image). If the intrinsic dimensions are overridden, the
replaced content is scaled by the user agent. When scaling an
element with intrinsic dimensions, the aspect ratio is
preserved if values for the 'width' and 'height' properties are
set to 'auto'.
Hybrid calculations
The dimension of a table cell is determined by both the cell's
contents and the surrounding available space.
The sections below describe these calculations in detail.
10.3 Box width calculations
As discussed in the section on box dimensions, the content width of a
box is assigned explicitly (via the 'width' property), given
"intrinsically" (for replaced elements), or calculated "top-down"
(based on the width of the box's containing block).
The following sections explain the exact computation of a box's
width-related properties.
10.3.1 Content width: the 'width' property
'width'
Value: | | auto | inherit
Initial: auto
Applies to: all elements but non-replaced inline elements,
table rows and row groups
Inherited: no
Percentages: refer to width of containing block
Media: visual
This property specifies the content width of a block box. Values have
the following meanings:
Specifies a fixed width.
Specifies a percentage width. The percentage is calculated with
respect to width of the generated box's containing block.
auto
See the section on widths of boxes in the normal flow and
floated boxes.
Negative values for 'width' are illegal. User agents must ignore this
property for elements with 'display' set to 'row' or 'row-span'.
For example, the following rule fixes the width of paragraphs to 100
pixels:
P { width: 100px }
10.3.2 Width of boxes in the normal flow and floated boxes
The 'width' property does not apply to non-replaced inline-level
elements. These elements generate boxes that flow into line boxes. The
width of line boxes is given by the their containing block, but may be
shorted by the presence of floats.
For other types of boxes in the normal flow and for floats, a box's
margin, padding, border, and content width must equal the width of its
containing block. These widths are specified with the following seven
properties: 'margin-left', 'border-left', 'padding-left', 'width',
'padding-right', 'border-right', and 'margin-right'. However, if the
'border-style' for an element has the value 'none', the corresponding
border widths will be '0'.
Three of these properties ('margin-left', 'width', and 'margin-right')
may take the value 'auto'. Their computed values are determined as
follows.
Determining the content width
When the 'width' property has the value 'auto', user agents should
assign it a computed value based on computed margin widths. In
addition:
1. For inline-level elements and those that generate floating boxes,
the computed value of 'width' is '0'.
2. For replaced elements, user agents should use the intrinsic width
of the element's rendered content as the box's computed width.
(Note that for other values of 'width', the replaced contents may
be scaled).
3. Minimum and maximum computed values for the 'width' property may
be assigned with the 'min-width' and 'max-width' properties.
Computing margin widths
User agents should assign computed values for 'margin-left', 'width',
and 'margin-right' as follows:
1. If exactly one of 'margin-left', 'width' or 'margin-right' has the
value 'auto', the computed value of that property is assigned so
that the seven width properties add up to the width of the
containing block.
2. If none of the properties has the value 'auto', 'margin-right' is
assigned a computed value so that the seven width properties add
up to the width of the containing block.
3. If more than one of the three has the value 'auto', and one of
them is 'width', than the other two ('margin-left' and/or
'margin-right') will be assigned the computed value '0' and
'width' will be assigned a computed value so that the seven width
properties add up to the width of the containing block.
4. Otherwise, if both 'margin-left' and 'margin-right' have the value
'auto', they will each be assigned a computed value that is half
of the available horizontal space (this centers the box within its
containing block).
10.3.3 Width of absolutely positioned boxes
The width of an absolutely positioned box may be computed in three
ways:
1. The element generating the box has a value other than 'auto' for
the 'width' property.
2. The element is a replaced element with an intrinsic width and
'width' has the value 'auto'.
3. The width is given by the difference between the 'left' and
'right' offsets (minus padding, borders, and margins). When
padding, border, and margin properties have the specified value
'auto', the computed value is '0'.
In cases one and two, for left-to-right formatting, values of 'left'
and 'right' are computed as follows:
* If both 'left' and 'right' have the value 'auto', 'left' is the
offset between the left containing block edge and the box's left
side as though it were in normal flow. Then 'right' is computed
based on the known left offset and width.
* If one property has a value other than 'auto', this known offset
and the width are used to calculate the offset of the opposite
side.
* If both properties have a value other than 'auto', 'right' is
treated as though it were 'auto'.
In case three, for left-to-right formatting, values of 'left',
'right', and 'width' are computed as follows:
* If 'right' has the value 'auto', it is assigned the value '0'. The
width is the (absolute) distance between the right containing
block edge and the box's left edge. A value of 'auto' for 'left'
means the left offset is calculated as though the box were in
normal flow.
* For other values of 'right', the width is the (absolute) distance
between the right offset and the position of the box's left edge,
calculated as before.
For all of the above cases, analogous rules hold for right-to-left
formatting, switching right and left.
10.3.4 Minimum and maximum widths: 'min-width' and 'max-width'
'min-width'
Value: | | inherit
Initial: 0
Applies to: all
Inherited: no
Percentages: refer to width of containing block
Media: visual
'max-width'
Value: | | inherit
Initial: 100%
Applies to: all
Inherited: no
Percentages: refer to width of containing block
Media: visual
These two properties allow authors to constrain box widths to a
certain range. Values have the following meanings:
Specifies a fixed minimum or maximum computed width.
Specifies a percentage for determining the computed value. The
percentage is calculated with respect to the width of the
generated box's containing block.
The following algorithm describes how the two properties influence the
computed value of the 'width' property:
1. the normal width is computed (without 'min-width' and
'max-width').
2. if the computed value of 'min-width' is greater than the value of
'max-width', 'max-width' is set to the value of 'min-width'.
3. if the computed width is greater than 'max-width', the computed
value of 'width' is set to the value of 'max-width'.
4. if the computed width is smaller than 'min-width', the computed
value of 'width' is set to the value of 'min-width'.
The user agent may define a non-negative minimum value for the 'width'
property, which may vary from element to element and even depend on
other properties. If 'width' goes below this limit, either because it
was set explicitly, or because it was 'auto' and the rules below would
make it too small, the user agent may use the minimum value as the
computed value.
10.4 Box height calculations
As discussed in the section on box dimensions, the content height of a
box is assigned explicitly (via the 'height' property), given
"intrinsically" (for replaced elements), or calculated as the minimal
height necessary to include the vertical content of the element and
that of all its flowed children. This is the height necessary before
any relative offset of children.
The following sections explain the exact computation of a box's
height-related properties.
10.4.1 Content height: the 'height' property
'height'
Value: | | auto | inherit
Initial: auto
Applies to: all elements but non-replaced inline elements,
table columns and column groups
Inherited: no
Percentages: see prose
Media: visual
This property specifies a box's content height. Values have the
following meanings:
Specifies a fixed height.
Specifies a percentage height. The percentage is calculated
with respect to the width of the generated box's containing
block.
auto
See the section on heights of boxes in the normal flow and
floated boxes.
Negative values for 'height' are illegal. User agents must ignore this
property for elements with 'display' set to 'col' or 'column-span'.
For example, the following rule fixes the height of paragraphs to 100
pixels:
P { height: 100px }
Paragraphs that require more than 100 pixels of height will overflow
according to the 'overflow' property.
The height may be enforced by the user interface (e.g., a scrollbar).
10.4.2 Determining the content height
When the 'height' property has the value 'auto', user agents should
assign it a computed value based on the space required by the
element's rendered content. In addition:
1. For replaced elements, user agents should use the intrinsic height
of the element's rendered content as the box's computed height.
(Note that for other values of 'height', the replaced contents may
be scaled).
2. Minimum and maximum computed values for the 'height' property may
be assigned with the 'min-height' and 'max-height' properties.
10.4.3 Height of absolutely positioned boxes
The height of an absolutely positioned box may be computed in three
ways:
1. The element generating the box has a value other than 'auto' for
the 'height' property.
2. The element is a replaced element with an intrinsic height and
'height' has the value 'auto'.
3. The height is given by the different between the 'top' and
'bottom' offsets (minus padding, borders, and margins). When
padding, border, and margin properties have the specified value
'auto', the computed value is '0'. In this case, the height of the
box's containing block must be known, otherwise the 'bottom' of
the box cannot be specified and the height is undefined.
In cases one and two, values of 'top' and 'bottom' are computed as
follows:
* If both 'top' and 'bottom' have the value 'auto', 'top' is the
offset between the top containing block edge and the box's top
side as though it were in normal flow. Then 'bottom' is computed
based on the known top offset and height.
* If one property has a value other than 'auto', this known offset
and the height are used to calculate the offset of the opposite
side.
* If both properties have a value other than 'auto', 'bottom' is
treated as though it were 'auto'.
In case three, the values of 'top', 'bottom', and 'height' are
computed as follows:
* If 'bottom' has the value 'auto', it is assigned the value '0'.
The height is the (absolute) distance between the bottom
containing block edge and the box's top edge. A value of 'auto'
for 'top' means the top offset is calculated as though the box
were in normal flow.
* For other values of 'bottom', the width is the (absolute) distance
between the bottom offset and the position of the box's top edge,
calculated as before.
10.4.4 Minimum and maximum heights: 'min-height' and 'max-height'
It is sometimes useful to constrain the height of elements to a
certain range. Two properties offer this functionality:
'min-height'
Value: | | inherit
Initial: 0
Applies to: all
Inherited: no
Percentages: refer to height of containing block
Media: visual
'max-height'
Value: | | inherit
Initial: 100%
Applies to: all
Inherited: no
Percentages: refer to height of containing block
Media: visual
These two properties allow authors to constrain box heights to a
certain range. Values have the following meanings:
Specifies a fixed minimum or maximum computed height.
Specifies a percentage for determining the computed value. The
percentage is calculated with respect to the generated box's
containing block.
The following algorithm describes how the two properties influence the
computed value of the 'height' property:
1. the normal height is computed (without 'min-height' and
'max-height').
2. if the value of 'min-height' is greater than the value of
'max-height', 'max-height' is set to the value of 'min-height'
3. if the calculated height is greater than 'max-height', the value
of 'height' is set to 'max-height'.
4. if the calculated height is smaller than 'min-height', the value
of 'height' is set to 'min-height'.
10.5 Line height calculations: the 'line-height' and 'vertical-align'
properties
As described in the section on inline formatting contexts, user agents
flow inline boxes into a vertical stack of line boxes. The height of a
line box is determined as follows:
1. The height of each inline box in the line box is calculated. The
height of an inline box is given by its 'line-height' property,
unless it is generated by a replaced element, in which case the
'height' property gives the height of the inline box.
2. The inline boxes are aligned vertically according to their
'vertical-align' property. If an element has the values 'top' or
'bottom' for this property, only the height of the generated boxes
affects the line box height calculation; the boxes cannot be
aligned until the line box has been fully constructed.
3. The line box height is the distance between the uppermost box top
and the lowermost box bottom.
Empty inline elements generate empty inline boxes, but these boxes
still have margins, padding, borders and a line height, and thus
influence these calculations just like elements with content.
Note that if all the boxes in the line box are aligned along their
bottoms, the line box will be exactly the height of the tallest box.
If, however, the boxes are aligned along a common baseline, the line
box top and bottom may not touch the top and bottom of the tallest
box.
Note that top and bottom margins, borders, and padding specified for
inline-level elements do not enter into the calculation of line box
heights but are visible (inside and outside line boxes).
10.5.1 Leading and half-leading
Since the height of an inline box may be different from the font size
of text in the box (e.g., 'line-height' > 1em), there may be space
above and below rendered glyphs. The difference between the font size
and the (actual) value of 'line-height' is called the leading. Half
the leading is called the half-leading.
User agents center the glyph vertically in the box, adding
half-leading on the top and bottom. For example, if a piece of text is
'12pt' high and the 'line-height' value is '14pt', 2pts of extra space
should be added: 1pt above and 1pt below the letters. (This applies to
empty boxes as well, as if the empty box contained an infinitely
narrow letter.)
When the 'line-height' value is less than the font size, the final
line box height will be less than the font size and the rendered
glyphs will "bleed" outside the box. If such a box touches the edge of
a line box, the rendered glyphs will also "bleed" into the adjacent
line box.
Although margins, borders, and padding do not enter into the line box
height calculation, they are still rendered around inline boxes
(except where boxes are split across lines). This means that if the
height of a line box is shorter than the outer edges of the boxes it
contains, backgrounds and colors may "bleed" into adjacent line boxes.
However, in this case, some user agents may use the line box to "clip"
the border and padding areas (i.e., not render them).
'line-height'
Value: normal | | | | inherit
Initial: normal
Applies to: all elements
Inherited: yes
Percentages: relative to the font size of the element itself
Media: visual
If the property is set on a block-level element whose content is
composed of inline-level elements, it specifies the minimal height of
each inline box.
If the property is set on an inline-level element, it specifies the
exact height of each box generated by the element. (Except for inline
replaced elements, where the height of the box is given by the
'height' property.)
Values for this property have the following meanings:
normal
Tells user agents to set the computed value to a "reasonable"
value based on the font size of the element. The value has the
same meaning as We recommend a number between 1.0 to
1.2.
The box height is set to this length. Negative values are
illegal.
The computed value of the property is this number multiplied by
the element's font size. Negative values are illegal. However,
the number, not the actual value, is inherited.
The actual value of the property is this percentage multiplied
by the element's font size. Negative values are illegal.
Note that replaced elements have a 'font-size' and a 'line-height'
property, even if they are not used directly to determine the height
of the box. The 'font-size' is, however, used to define the 'em' and
'ex' units, and the 'line-height' has a role in the 'vertical-align'
property.
The three rules in the example below have the same resultant line
height:
DIV { line-height: 1.2; font-size: 10pt } /* number */
DIV { line-height: 1.2em; font-size: 10pt } /* length */
DIV { line-height: 120%; font-size: 10pt } /* percentage */
When an element contains text that is rendered in more than one font,
user agents should determine the 'line-height' value according to the
largest font size.
Generally, when there is only one value of 'line-height' for all
inline boxes in a paragraph (and no tall images), the above will
ensure that baselines of successive lines are exactly 'line-height'
apart. This is important when columns of text in different fonts have
to be aligned, for example in a table.
'vertical-align'
Value: baseline | sub | super | top | text-top | middle |
bottom | text-bottom | | | inherit
Initial: baseline
Applies to: inline-level and table cell elements
Inherited: no
Percentages: refer to the 'line-height' of the element itself
Media: visual
This property affects the vertical positioning inside a line box of
the boxes generated by an inline-level element. The following values
only have meaning with respect to a parent inline-level element, or to
a parent block-level element, if that element generates anonymous
inline boxes; they have no effect if no such parent exists
Note. Values of this property have slightly different meanings in the
context of tables. Please consult the section on vertical alignment of
table context for details.
baseline
Align the baseline of the box with the baseline of the parent
box. If the box doesn't have a baseline, align the bottom of
the box with the parent's baseline.
middle
Align the vertical midpoint of the box with the baseline of the
parent box plus half the x-height of the parent.
sub
Lower the baseline of the box to the proper position for
subscripts of the parent's box. (This value has no effect on
the font size of the element's text.)
super
Raise the baseline of the box to the proper position for
superscripts of the parent's box. (This value has no effect on
the font size of the element's text.)
text-top
Align the top of the box with the top of the parent element's
font.
text-bottom
Align the bottom of the box with the bottom of the parent
element's font.
Raise (positive value) or lower (negative value) the box by
this distance (a percentage of the 'line-height' value). The
value '0%' means the same as 'baseline'.
Raise (positive value) or lower (negative value) the box by
this distance. The value '0cm' means the same as 'baseline'.
The remaining values refer to the line box in which the generated box
appears:
top
Align the top of the box with the top of the line box.
bottom
Align the bottom of the box with the bottom of the line box.
_________________________________________________________________
_________________________________________________________________
11 Visual effects
Contents
* 11.1 Overflow and clipping
+ 11.1.1 Overflow: the 'overflow' property
+ 11.1.2 Clipping: the 'clip' property
* 11.2 Visibility: the 'visibility' property
The visual effects discussed in these sections do not alter layout,
only presentation.
11.1 Overflow and clipping
Generally, the contents of a block box are confined within the content
edges of the box. In certain cases, a box may overflow, meaning its
content lies partly or entirely outside of the block:
* Content is too wide for the containing block. This may happen when
an element's 'width' property has a value that causes the
generated box (or inline boxes) to spill over sides of the
containing block. An inline replaced element (e.g., an image) that
has a large intrinsic width may also overflow.
* An element's height exceeds an explicit height assigned to the
containing block (i.e., the containing block's height is
determined by the 'height' property, not by content height).
* It is positioned absolutely.
* It has negative margins.
Whenever overflow occurs, the 'overflow' property specifies how a box
is clipped. The 'clip' property specifies the size and shape of the
clipping region. Specifying a small clipping region may cause clipping
of otherwise visible contents.
11.1.1 Overflow: the 'overflow' property
'overflow'
Value: visible | hidden | scroll | auto | inherit
Initial: visible
Applies to: block-level and replaced elements
Inherited: no
Percentages: N/A
Media: visual
This property specifies whether the contents of a block-level element
are clipped when they overflow the element's box. Values have the
following meanings:
visible
This value indicates that nested boxes are not clipped, i.e.,
they may be rendered outside the block box.
hidden
This value indicates that the boxes are clipped and that no
scrolling mechanism should be provided to view the content
outside the clipping region; users will not have access to
clipped content. The size and shape of the clipping region is
specified by the 'clip' property.
scroll
This value indicates that if the user agent supports a visible
scrolling mechanism, that mechanism should be displayed for a
box whether or not any of its content is clipped. This avoids
any problem with scrollbars appearing and disappearing in a
dynamic environment. When this value is specified and the
target medium is 'print' or 'projection', overflowing content
should be printed.
auto
The behavior of the 'auto' value is user agent-dependent, but
should cause a scrolling mechanism to appear for overflowing
boxes.
Even if 'overflow' is set to 'visible', contents may be clipped to a
UA's document window by the native operating environment.
Consider the following example, of a block quotation (BLOCKQUOTE) that
is too big for its containing block (established by a DIV). Here is
the source document:
I didn't like the play, but then I saw
it under adverse conditions - the curtain was up.
- Groucho Marx
Here is the style sheet controlling the sizes and style of the
generated boxes:
DIV { width : 100px; height: 100px;
border: thin solid red
}
BLOCKQUOTE { width : 125px; height : 100px;
position: absolute;
top: 50px; left: 50px;
border: thin dashed black
}
DIV.attributed-to { text-align : right; }
The initial value of 'overflow' is 'visible', so the BLOCKQUOTE would
be formatted without clipping, something like this:
Rendered overflow
Setting 'overflow' to 'hidden' for the DIV element, on the other hand,
causes the BLOCKQUOTE to be clipped by the containing block:
Clipped overflow
A value of 'scroll' would tell UAs that support a visible scrolling
mechanism to display one so that users could access the clipped
content.
11.1.2 Clipping: the 'clip' property
A clipping region defines what portion of an element's rendered
content is visible. By default, the clipping region for an element has
the dimensions of the containing block of its generated boxes.
However, the clipping region may be modified by the 'clip' property.
'clip'
Value: | auto | inherit
Initial: auto
Applies to: block-level and replaced elements
Inherited: no
Percentages: N/A
Media: visual
Values have the following meanings:
auto
The clipping region for boxes generated by this element is the
same size as the boxes themselves.
In CSS2, the only valid value is: rect (
) where , , and
specify offsets from the respective sides of the box.
, , , and may either have a
value or 'auto'. Negative lengths are permitted. The value
'auto' means that a given edge of the clipping region will be
the same as the edge of the element's generated box. (I.e.,
'auto' is the same as '0'.)
When converted to pixel coordinates, the bottom-right corner is
excluded from the clipping rectangle. This rule is necessary to
permit the definition of zero-width or zero-height rectangles.
If the clipping region exceeds the bounds of the UA's document window,
contents may be clipped to that window by the native operating
environment.
The following two rules:
P { clip: rect(5px, 10px, 10px, 5px); }
P { clip: rect(5px, -5px, 10px, 5px); }
will create the rectangular clipping regions delimited by the dotted
line in the following illustrations:
Two clipping regions
Note. In CSS2, all clipping regions are rectangular. We anticipate
future extensions to permit non-rectangular clipping.
11.2 Visibility: the 'visibility' property
'visibility'
Value: visible | hidden | collapse | inherit
Initial: inherit
Applies to: all elements
Inherited: no
Percentages: N/A
Media: visual
The 'visibility' property specifies whether the boxes generated by an
element are rendered. Invisible boxes still affect layout (set the
'display' property to 'none' to suppress box generation altogether).
Values have the following meanings:
visible
The generated box is visible.
hidden
The generated box is invisible, but still affects layout.
collapse
Please consult the section on dynamic row and column effects in
tables. If used on elements other than rows or columns,
'collapse' has the same meaning as 'hidden'.
This property may be used in conjunction with scripts to create
dynamic effects.
In the following example, pressing either form button invokes a
user-defined script function that causes the corresponding box to
become visible and the other to be hidden. Since these boxes have the
same size and position, the effect is that one replaces the other.
Choose a suspect:
Name: Al Capone
Residence: Chicago
Name: Lucky Luciano
Residence: New York
Note that the 'position' property of each DIV element has the value
'relative'. A more visually appealing version of the above might be
designed using overlapping absolutely positioned boxes.
_________________________________________________________________
_________________________________________________________________
12 Generated content and automatic numbering
Contents
* 12.1 The :before and :after pseudo-elements
* 12.2 The 'content' property
* 12.3 Interaction of :before and :after with 'compact' and 'run-in'
elements
* 12.4 Quotation marks
+ 12.4.1 Specifying quotes with the 'quotes' property
+ 12.4.2 Inserting quotes with the 'content' property
* 12.5 Automatic counters and numbering
+ 12.5.1 Nested counters and scope
+ 12.5.2 Counter styles
+ 12.5.3 Counters in elements with 'display: none'
* 12.6 Markers
In some cases, authors may want user agents to render content that
does not come from the document tree. One familiar example of this is
a numbered list; the author does not want to list the numbers
explicitly, he or she wants the user agent to generate them
automatically. Similarly, authors may want the user agent to insert
the word "Figure" before the caption of a figure, or "Chapter 7"
before the seventh chapter title. For audio or braille in particular,
user agents should be able to insert these strings.
In CSS2, content may be generated by several mechanisms:
* The 'content' property, in conjunction with the :before and :after
pseudo-elements.
* The 'cue-before', 'cue-after' aural properties. When the aural
properties are specified as well as the the 'content' property,
content is rendered in the following order: :before, 'cue-before',
('pause-before'), the element's content, ('pause-after'),
'cue-after', and :after.
* Elements with a value of 'list-item' for the 'display' property.
Below we describe the mechanisms associated with the 'content'
property.
12.1 The :before and :after pseudo-elements
Authors specify the style and location of generated content with the
:before and :after pseudo-elements. The 'content' property, in
conjunction with these pseudo-elements, specifies what is inserted. As
their names indicate, the :before and :after pseudo-elements specify
content before and after an element's document tree content.
For example, the following rules insert the keyword "Note: " before
the content of every P element whose "class" attribute has the value
"note":
P.note:before { content: "Note: " }
The rendering objects (e.g., boxes) generated by an element include
generated content. So, for example, changing the above style sheet to:
P.note:before { content: "Note: ";
border: solid green}
would cause a solid green border to be rendered around the entire
paragraph, including the initial string.
The :before and :after pseudo-elements inherit any inheritable
properties from the element in the document tree to which they are
attached.
For example, the following rules insert an open quote mark before
every Q element. The color of the quote mark will be red, but the font
will be the same as the font of the rest of the Q element:
Q:before {
content: open-quote;
color: red
}
In a :before or :after pseudo-element declaration, non-inherited
properties take their initial values.
So, for example, because the initial value of the 'display' property
is 'inline', the quote in the previous example is inserted as an
inline box (i.e., on the same line as the element's initial text
content). The next example explicitly sets the 'display' property to
'block', so that the inserted text becomes a block:
BODY:after {
content: "The End";
display: block;
margin-top: 2em;
text-align: center;
}
Note that an audio user agent would speak the words "The End" after
rendering the rest of the BODY content.
User agents must ignore the following properties with :before and
:after pseudo-elements: 'position', 'float', list properties, and
table properties.
The :before and :after pseudo-elements elements allow values of the
'display' property as follows:
* If the subject of the selector is a block-level element, allowed
values are 'none', 'inline', 'block', and 'marker'. If the value
of the 'display' has any other value, the pseudo-element will
behave as if the value were 'block'.
* If the subject of the selector is an inline-level element, allowed
values are 'none' and 'inline'. If the value of the 'display' has
any other value, the pseudo-element will behave as if the value
were 'inline'.
Note. Other values may be permitted in future levels of CSS.
12.2 The 'content' property
'content'
Value: [ | | | attr(X) | open-quote
| close-quote | no-open-quote | no-close-quote ]+ | inherit
Initial: empty string
Applies to: :before and :after pseudo-elements
Inherited: no
Percentages: N/A
Media: all
This property is used with the :before and :after pseudo-elements to
generate content in a document. The 'display' property controls
whether the content is placed in an inline or block box.
The values have the following meanings:
Text content.
The value is a URI that designates an external resource. If a
user agent cannot support the resource because of the media
types it supports, it must ignore the resource. Note. CSS2
offers no mechanism to change the size of the embedded object,
or to provide a textual description, like the "alt" or
"longdesc" attributes do for images in HTML. This may change in
future levels of CSS.
Counters may be specified with two different functions:
'counter()' or 'counters()'. The former has two forms:
'counter(name)' or 'counter(name, style)'. The generated text
is the value of the named counter at this point in the
rendering structure, in the indicated style ('decimal' by
default). The latter also has two forms: 'counter(name,
string)' or 'counter(name, string, style)'. The generated text
is the value of all counters with the given name at this point
in the rendering structure, separated by the specified string.
The counters are rendered in the indicated style ('decimal' by
default).
open-quote and 'close-quote'
Both of these values are replaced by the appropriate string
from the 'quotes' property.
no-open-quote and no-close-quote
Inserts nothing (the empty string), but increments, resp.
decrements the level of nesting for quotes.
attr(X)
This function returns the value of attribute X as a string. The
string is not parsed by the CSS processor. If the current
element doesn't have an attribute X, an empty string is
returned. The case-sensitivity of attribute names depends on
the document language.
Authors should put 'content' declarations in @media rules when the
content requires media consideration. For instance, literal text may
be used for any media group, but images only apply to the visual,
bitmap media groups, and sound files only apply to the aural media
group.
The following rule causes a sound file to be played at the end of a
quotation (see the section on aural style sheets for additional
mechanisms):
@media aural {
BLOCKQUOTE:after {content: url(beautiful-music.wav)}
}
The next rule inserts the text of the HTML "alt" attribute before the
image. If the image is not displayed, the reader will still see the
"alt" text.
IMG:before {content: attr(alt)}
Authors may include newlines in the generated content by writing the
"\A" escape sequence in one of the strings after the 'content'
property. This inserts a forced line break, similar to the BR element
in HTML. See "Strings" and "Characters and case" for more information
on the "\A" escape sequence.
Example:
H1:before {
display: block;
text-align: center;
content: "chapter\A hoofdstuk\A chapitre"
}
Generated content does not alter the document tree. In particular, it
is not fed back to the document language processor (e.g., for
reparsing).
Note. In future levels of CSS, the 'content' property may accept
additional values, allowing it to vary the style of pieces of the
generated content, but in CSS2, the content of the :before or :after
pseudo-element all has the same style.
12.3 Interaction of :before and :after with 'compact' and 'run-in' elements
The following cases can occur:
1. A 'run-in' or 'compact' element has a :before pseudo-element of
type 'inline': the pseudo-element is taken into account when the
size of the element is computed (for 'compact') and is rendered
inside the same block box as the element.
2. A 'run-in' or 'compact' element has an :after pseudo-element of
type 'inline': ditto.
3. A 'run-in' or 'compact' element has a :before pseudo-element of
type 'block': the pseudo-element is rendered as a block above the
element, and does not take part in the computation of the
element's size (for 'compact').
4. A 'run-in' or 'compact' element has an :after pseudo-element of
type 'block': both the element and its :after pseudo-element are
rendered as block boxes. The element is not rendered as an inline
box in its own :after pseudo-element.
5. The element following a 'run-in' or 'compact' element has a
:before of type 'block': the decision how to render the
'run-in'/'compact' element is made with respect to the block box
resulting from the :before pseudo-element.
6. The element following a 'run-in' or 'compact' element has an
:before of type 'inline': the decision how to render the
'run-in'/'compact' element depends on the type of the element to
which the :before is attached.
Here is an example of a 'run-in' header with an :after pseudo-element,
followed by a paragraph with a :before pseudo-element. All
pseudo-elements are inline (the default) in this example. When the
style sheet:
H3 { display: run-in }
H3:after { content: ": " }
P:before { content: "... " }
is applied to this source document:
Centaurs
have hoofs
have a tail
The visual rendering will resemble:
Centaurs: ... have hoofs
... have a tail
12.4 Quotation marks
In CSS2, authors may specify how user agents should render quotation
marks in a style-sensitive and context-dependent manner. The 'quotes'
property specifies pairs of quotation marks for each level of embedded
quotation. The 'content' property gives access to those quotation
marks and causes them to be inserted before and after a quotation.
12.4.1 Specifying quotes with the 'quotes' property
'quotes'
Value: [ ]+ | none | inherit
Initial: depends on user agent
Applies to: all elements
Inherited: yes
Percentages: N/A
Media: visual
This property specifies quotation marks for any number embedded
quotations. Values have the following meanings:
none
The 'open-quote' and 'close-quote' values of the 'content'
property produce no quotations marks.
[ ]+
Values for the 'open-quote' and 'close-quote' values of the
'content' property are taken from this list of pairs of
quotation marks (opening and closing). The first (leftmost)
pair represents the outermost level of quotation, the second
pair the first level of embedding, etc. The user agent must
apply the appropriate pair of quotation marks according to the
level of embedding.
For example, applying the following style sheet:
/* Specify pairs of quotes for two levels in two languages */
Q:lang(en) { quotes: '"' '"' "'" "'" }
Q:lang(no) { quotes: "«" "»" "'" "'" }
/* Insert quotes before and after Q element content */
Q :before { content : open-quote }
Q :after { content : close-quote }
to the following HTML fragment:
Quote me!
would allow a user agent to render:
"Quote me!"
while this HTML fragment:
Han sa vet ikke !
would produce:
«Han sa 'vet ikke'!»
Note. While the quotation marks specified by 'quotes' in the previous
examples are conveniently located on computer keyboards, high quality
typesetting would require different ISO 10646 characters. The
following informative table lists some of the ISO 10646 quotation mark
characters:
Ascii approximation ISO 10646 code (hex) Description
" 0022 QUOTATION MARK [the ASCII double quotation mark]
' 0027 APOSTROPHE [the ASCII single quotation mark]
[2039 SINGLE LEFT-POINTING ANGLE QUOTATION MARK
[>] 203A SINGLE RIGHT-POINTING ANGLE QUOTATION MARK
« 00AB LEFT-POINTING DOUBLE ANGLE QUOTATION MARK
» 00BB RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK
[`] 2018 LEFT SINGLE QUOTATION MARK [single high-6]
['] 2019 RIGHT SINGLE QUOTATION MARK [single high-9]
[``] 201C LEFT DOUBLE QUOTATION MARK [double high-6]
[''] 201D RIGHT DOUBLE QUOTATION MARK [double high-9]
[,,] 201E DOUBLE LOW-9 QUOTATION MARK [double low-9]
12.4.2 Inserting quotes with the 'content' property
Quotation marks are inserted in appropriate places in a document with
the 'open-quote' and 'close-quote' values of the 'content' property.
Each occurrence of 'open-quote' or 'close-quote' is replaced by one of
the strings from the value of 'quotes', based on the depth of nesting.
'Open-quote' refers to the first of a pair of quotes, 'close-quote'
refers to the second. Which pair of quotes is used depend on the
nesting level of quotes: the number of occurrences of 'open-quote' in
all generated text before the current occurrence, minus the number of
occurrences of 'close-quote'. If the depth is 0, the first pair is
used, if the depth is 1, the second pair is used, etc. If the depth is
greater than the number of pairs, the last pair is repeated.
Note that this quoting depth is independent of the nesting of the
source document or the rendering structure.
Some typographic styles require open quotation marks to be repeated
before every paragraph of a quote spanning several paragraphs, but
only the last paragraph ends with a closing quotation mark. In CSS,
this can be achieved by inserting "phantom" closing quotes. The
keyword 'no-close-quote' decrements the quoting level, but does not
insert a quotation mark.
The following style sheet puts opening quotation marks on every
paragraph in a BLOCKQUOTE, and inserts a single closing quote at the
end:
BLOCKQUOTE P:before { content: open-quote }
BLOCKQUOTE P:after { content: no-close-quote }
BLOCKQUOTE P.last:after { content: close-quote }
This relies on the last paragraph being marked with a class "last",
since there are no selectors that can match the last child of an
element.
For symmetry, there is also a 'no-open-quote' keyword, which inserts
nothing, but increments the quotation depth by one.
Note. If a quotation is in a different language than the surrounding
text, it is customary to quote the text with the quote marks of the
language of the surrounding text, not the language of the quotation
itself. For example, French inside English:
The device of the order of the garter is “Honi soit qui mal y
pense.”
English inside French:
Il disait: « Il faut mettre l'action en ‹ fast
forward ›.»
A style sheet like the following will set the 'quotes' property so
that 'open-quote' and 'close-quote' will work correctly on all
elements. These rules are for documents that contain only English,
French, or both. One rule is needed for every additional language.
Note the use of the child combinator (">") to set quotes on elements
based on the language of the surrounding text:
[LANG|=fr] > * {quotes: "«" "»" "\2039" "\203A"}
[LANG|=en] > * {quotes: "\201C" "\201D" "\2018" "\2019"}
The quotation marks for English are shown here in a form that most
people will be able to type. If you can type them directly, they will
look like this:
[LANG|=fr] > * {quotes: "«" "»" "‹" "›"}
[LANG|=en] > * {quotes: "“" "”" "‘" "’"}
12.5 Automatic counters and numbering
Automatic numbering in CSS2 is controlled with two properties,
'counter-increment' and 'counter-reset'. The counters defined by these
properties can be used to generate text for the 'content' property
(see the counter() function).
'counter-reset'
Value: [ ? ]+ | none | inherit
Initial: none
Applies to: all elements
Inherited: no
Percentages: N/A
Media: all
'counter-increment'
Value: [ ? ]+ | none | inherit
Initial: none
Applies to: all elements
Inherited: no
Percentages: N/A
Media: all
The 'counter-increment' property accepts one or more names of counters
(identifiers), each one optionally followed by an integer. The integer
indicates by how much the counter is incremented for every occurrence
of the element. The default increment is 1. Zero and negative integers
are allowed.
The 'counter-reset' property also contains a list of one or more names
of counters, each one optionally followed by an integer. The integer
gives the value that the counter is set to on each occurrence of the
element. The default is 0.
If 'counter-increment' refers to a counter that is not in the scope
(see below) of any 'counter-reset', the counter is assumed to have
been reset to 0 by the root element.
This example shows a way to number chapters and sections with "Chapter
1", "1.1", "1.2", etc.
H1:before {
content: "Chapter " counter(chapter) ". ";
counter-increment: chapter; /* Add 1 to chapter */
counter-reset: section; /* Set section to 0 */
}
H2:before {
content: counter(chapter) "." counter(section) " ";
counter-increment: section;
}
If an element increments/resets a counter and also uses it (in the
'content' property of its :before or :after pseudo-element), the
counter is used after being incremented/reset.
If an element both resets and increments a counter, the counter is
reset first and then incremented.
The 'counter-reset' property follows the cascading rules. Thus, due to
cascading, the following stylesheet:
H1 {counter-reset: section -1}
H1 {counter-reset: imagenum 99}
will only reset 'imagenum'. To reset both counters, they have to be
specified together:
H1 {counter-reset: section -1 imagenum 99}
12.5.1 Nested counters and scope
Counters are "self-nesting", in the sense that re-using a counter in a
child element automatically creates a new instance of the counter.
This is important for situations like lists in HTML, where elements
can be nested inside themselves to arbitrary depth. It would be
impossible to define uniquely named counters for each level.
Thus the following suffices to number nested list items. The result is
very similar to that of setting 'display:list-item' and 'list-style:
inside' on the LI element:
OL {counter-reset: item}
LI {display: block}
LI:before {content: counter(item) ". "; counter-increment: item}
The self-nesting is based on the principle that every element that has
a 'counter-reset' for a counter X, creates a fresh counter X, the
scope of which is the element, its younger siblings, and all the
descendants of the element and its younger siblings.
In the example above, an OL will create a counter, and all children of
the OL will refer to that counter.
If we denote by item[n] the nth counter, and by "(" and ")" the
beginning and end of a scope, then the following HTML fragment will
use the indicated counters. (We assume the style sheet as given in the
example above).
item
item
item
item
item
item
item
item
item
item
item
The 'counters()' function generates a string composed of all counters
with the same name, separated by a given string.
The following style sheet numbers nested list items as "1", "1.1",
"1.1.1", etc.
OL {counter-reset: item}
LI {display: block}
LI:before {content: counters(item, "."); counter-increment: item}
12.5.2 Counter styles
By default, counters are rendered with decimal numbers, but all the
styles available for the 'list-style-type' property are also available
for counters. The notation is:
counter(name)
for the default, decimal style, or:
counter(name, 'list-style-type')
All the styles are allowed, including 'disc', 'circle', 'square', and
'none'.
Examples:
H1:before { content: counter(chno, upper-latin) ". " }
H2:before { content: counter(section, upper-roman) " - " }
BLOCKQUOTE:after { content: " [" counter(bq, hebrew) "]" }
DIV.note:before { content: counter(notecntr, disc) " " }
P:before { content: counter(p, none) }
12.5.3 Counters in elements with 'display: none'
An element that is not displayed ('display' set to 'none') cannot
increment or reset a counter.
For example, with the following style sheet, H2s with class "secret"
do not increment 'count2'.
H2.secret {counter-increment: count2; display: none}
Elements with 'visibility' set to 'hidden', on the other hand, do
increment counters.
12.6 Markers
There are very few situations in CSS2 where an element causes the
generation of more than one box. The most common case occurs for
elements with 'display: list-item' (see the section on lists). The two
generated boxes are the principal box (the list item content) and the
list item marker (to the side of the principal box). Authors have very
limited control of the style or position of the list item marker
through the list style properties.
Markers are used together with the :before and :after pseudo-elements
to offer similar functionality, but give authors more control over the
position of the generated content. Markers may be used with automatic
counters to create a wider variety of list styles than available with
the list properties. They may also be used to create numbered margin
notes, etc.
An element may generate two marker boxes: one for :before content and
one for :after content, in addition to one principal box (that of the
element's content). Marker boxes must only contain one line of content
(i.e., one line box), so they are not as flexible as floats, which may
be used to align entire blocks horizontally.
Marker boxes have padding and borders, but no margins.
To create a marker box for :before or :after content, the 'display'
property must be given the value 'marker'. The marker box is only
created if the 'content' property for the pseudo-element actually
generates content. The content will be formatted as a single line.
For the :before pseudo-element, the baseline of text in the marker box
will be vertically aligned with the baseline of text in the first line
of content in the principal box. If the principal box contains no
text, the top outer edge of the marker box will be aligned with the
top outer edge of the principal box. For the :after pseudo-element,
the baseline of text in the marker box will be vertically aligned with
the baseline of text in the last line of content in the principal box.
If the principal box contains no text, the bottom outer edge of the
marker box will be aligned with the bottom outer edge of the principal
box.
The vertical alignment of content within the marker box may be
specified with the 'vertical-align' property.
The height of the :before marker and of the first line box of the
principal box is computed as if they were a single line box.
Analogously for the :after marker and the last line box. The
'line-height' property sets the height of the marker box.
The width of a marker box defaults to the natural width of its
content, but may be specified with the 'width' property. If the width
of a marker box's content is greater than the specified width, the
'overflow' property specifies overflow behavior. Marker boxes may
overlap principal boxes.
If the 'width' is not 'auto', and is larger than the natural width,
the 'text-align' property determines the horizontal alignment of the
content in the marker box.
The 'marker-offset' property specifies the horizontal offset between a
marker box and the associated principal box. The distance is measured
between their nearest border edges.
When the 'display' property has the value 'marker' for content
generated by an element with 'display: list-item', a marker box
generated for ':before' replaces the normal list item marker.
The following example illustrates how markers may be used to add
periods after each numbered list item. This HTML program and style
sheet:
This is the first item.
This is the second item.
This is the third item.
should produce something like this:
i. This is the first item.
ii. This is the second item.
iii. This is the third item.
This next example shows a different horizontal alignment: the content
is centered within a box of a fixed width. This document:
This is the first item.
This is the second item.
This is the third item.
should produce something like this:
(1) This is the
first item.
(2) This is the
second item.
(3) This is the
third item.
The next example creates markers before and after list items. This
document:
first list item comes first
second list item comes second
should produce something like this (ascii art is used instead of
smiley gif images here):
:-) first list item
comes first :-(
:-) second list item
comes second :-(
The next example uses markers to number notes (paragraphs). The
following document:
This is the first paragraph in this document.
This is a very short document.
This is the end.
should produce something like:
This is the first paragraph
in this document.
Note 1: This is a very short
document.
This is the end.
'marker-offset'
Value: | auto | inherit
Initial: auto
Applies to: elements with 'display' set to 'marker'
Inherited: no
Percentages: N/A
Media: visual
This property specifies the distance between the nearest border edges
of a marker box and its associated principal box. The offset may
either be a user-specified () or chosen by the UA ('auto').
Lengths may be negative, but there may be implementation-specific
limits.
The following example illustrates how markers may be used to add
periods after each numbered list item. This HTML program and style
sheet:
This is a long preceding paragraph ...
This is the first item.
This is the second item.
This is the third item.
This is a long following paragraph ...
should produce something like this:
This is a long preceding
paragraph ...
i. This is the first item.
ii. This is the second item.
iii. This is the third item.
This is a long following
paragraph ...
_________________________________________________________________
_________________________________________________________________
13 Paged media
Contents
* 13.1 Introduction to paged media
* 13.2 Page boxes: the @page rule
+ 13.2.1 Page margins
+ 13.2.2 Page size: the 'size' property
o Rendering page boxes that do not fit a target sheet
o Positioning the page box on the sheet
+ 13.2.3 Crop marks: the 'marks' property
+ 13.2.4 Left, right, and first pages
+ 13.2.5 Content outside the page box
* 13.3 Page breaks
+ 13.3.1 Break before/after elements: 'page-break-before',
'page-break-after', 'page-break-inside'
+ 13.3.2 Using named pages: 'page'
+ 13.3.3 Breaks inside elements: 'orphans', 'widows', and
'page-break-inside'
+ 13.3.4 Allowed page breaks
+ 13.3.5 Forced page breaks
+ 13.3.6 "Best" page breaks
* 13.4 Cascading in the page context
13.1 Introduction to paged media
Paged media (e.g., paper, transparencies, pages that are displayed on
computer screens, etc.) differ from continuous media in that the
content of the document is split into one or more discrete pages. To
handle page breaks, CSS2 extends the visual rendering model as
follows:
1. The page box extends the box model to allow authors to specify the
size of a page, its margins, etc.
2. The page model extends the visual rendering layout model to
account for page breaks.
The CSS2 page model specifies how a document is formatted within a
rectangular area -- the page box -- that has a finite width and
height. The page box does not necessarily correspond to the real sheet
where the document will ultimately be rendered (paper, transparency,
screen, etc.). The CSS page model specifies formatting in the page
box, but it is the user agent's responsibility to transfer the page
box to the sheet. Some transfer possibilities include:
* Transferring one page box to one sheet (e.g., single-sided
printing).
* Transferring two page boxes to both sides of the same sheet (e.g.,
double-sided printing).
* Transferring N (small) page boxes to one sheet (called "n-up").
* Transferring one (large) page box to N x M sheets (called
"tiling").
* Creating signatures. A signature is a group of pages printed on a
sheet, which, when folded and trimmed like a book, appear in their
proper sequence.
* Printing one document to several output trays.
* Outputting to a file.
Although CSS2 does not specify how user agents transfer page boxes to
sheets, it does include certain mechanisms for telling user agents
about the target sheet size and orientation.
13.2 Page boxes: the @page rule
The page box is a rectangular region that contains two embedded areas:
* The page area. The page area includes the boxes laid out on that
page. The edges of the page area act as a containing block for
layout that occurs between page breaks. It also acts as the
initial containing block.
* The margin area.
Note. In CSS2, the border properties and padding properties do not
apply to pages; they may in the future.
Authors specify the dimensions, orientation, margins, etc. of a page
box within an @page rule. An @page rule consists of the keyword
"@page", a page selector, and a block of declarations (said to be in
the page context).
The page selector specifies for which pages the declarations apply. In
CSS2, page selectors may designate the first page, all left pages, all
right pages, or a page with a specific name.
The dimensions of the page box are set with the 'size' property. The
'marks' property specifies crop and cross marks.
For example, the following @page rule sets the margins of the page to
2cm.
@page { margin: 2cm }
13.2.1 Page margins
The margin properties ('margin-top', 'margin-right', 'margin-bottom',
'margin-left', and 'margin') apply within the page context. The
following diagram shows the relationships between the sheet, page box,
and page margins:
Illustration of sheet, page box, and margin.
The actual value of element margins that fall at the top or bottom of
a page is set to 0.
The page context has no notion of fonts, so 'em' and 'ex' units are
not allowed. Percentage values on the margin properties are relative
to the dimensions of the page box. All other units associated with the
respective CSS2 properties are allowed.
Due to negative margin values (either on the page box or on elements)
or absolute positioning content may end up outside the page box, but
this content may be "cut" -- by the user agent, the printer, or
ultimately, the paper cutter.
13.2.2 Page size: the 'size' property
'size'
Value: {1,2} | auto | portrait | landscape | inherit
Initial: auto
Applies to: page context
Inherited: N/A
Percentages: N/A
Media: visual, paged
This property specifies the size and orientation of a page box.
The size of a page box may either be "absolute" (fixed size) or
"relative" (scalable, i.e., fitting available sheet sizes). Relative
page boxes allow user agents to scale a document and make optimal use
of the target size.
Three values for the 'size' property create a relative page box:
auto
The page box will be set to the size and orientation of the
target sheet.
landscape
Overrides the target's orientation. The page box is the same
size as the target, and the longer sides are horizontal.
portrait
Overrides the target's orientation. The page box is the same
size as the target, and the shorter sides are horizontal.
In the following example, the outer edges of the page box will align
with the target. The percentage value on the 'margin' property is
relative to the target size so if the target sheet dimensions are
21.0cm x 29.7cm (i.e., A4), the margins are 2.10cm and 2.97cm.
@page {
size: auto; /* auto is the initial value */
margin: 10%;
}
Length values for the 'size' property create an absolute page box. If
only one length value is specified, it sets both the width and height
of the page box (i.e., the box is a square). Since the page box is the
initial containing block, percentage values are not allowed for the
'size' property.
For example:
@page {
size: 8.5in 11in; /* width height */
}
The above example set the width of the page box to be 8.5in and the
height to be 11in. The page box in this example requires a target
sheet size of 8.5"x11" or larger.
User agents may allow users to control the transfer of the page box to
the sheet (e.g., rotating an absolute page box that's being printed).
Rendering page boxes that do not fit a target sheet
If the page box does not fit the target sheet dimensions, the user
agent may choose to:
* Rotate the page box 90° if this will make the page box fit.
* Scale the page to fit the target.
The user agent should consult the user before performing these
operations.
Positioning the page box on the sheet
When the page box is smaller than the target size, the user agent is
free to place the page box anywhere on the sheet. However, it is
recommended that the page box be centered on the sheet since this will
align double-sided pages and avoid accidental loss of information that
is printed near the edge of the sheet.
13.2.3 Crop marks: the 'marks' property
'marks'
Value: [ crop || cross ] | none | inherit
Initial: none
Applies to: page context
Inherited: N/A
Percentages: N/A
Media: visual, paged
In high-quality printing, marks are often added outside the page box.
This property specifies whether cross marks or crop marks or both
should be rendered just outside the page box edge.
Crop marks indicate where the page should be cut. Cross marks (also
known as register marks or registration marks) are used to align
sheets.
Marks are visible only on absolute page boxes (see the 'size'
property). In relative page boxes, the page box will be aligned with
the target and the marks will be outside the printable area.
The size, style, and position of cross marks depend on the user agent.
13.2.4 Left, right, and first pages
When printing double-sided documents, the page boxes on left and right
pages should be different. This can be expressed through two CSS
pseudo-classes that may be defined in the page context.
All pages are automatically classified by user agents into either the
:left or :right pseudo-class.
@page :left {
margin-left: 4cm;
margin-right: 3cm;
}
@page :right {
margin-left: 3cm;
margin-right: 4cm;
}
If different declarations have been given for left and right pages,
the user agent must honor these declarations even if the user agent
does not transfer the page boxes to left and right sheets (e.g., a
printer that only prints single-sided).
Authors may also specify style for the first page of a document with
the :first pseudo-class:
@page { margin: 2cm } /* All margins set to 2cm */
@page :first {
margin-top: 10cm /* Top margin on first page 10cm */
}
Whether the first page of a document is :left or :right depends on the
major writing direction of the document and is outside the scope of
this document. However, to force a :left or :right first page, authors
may insert a page break before the first generated box (e.g., in HTML,
specify this for the BODY element).
Properties specified in a :left (or :right) @page rule override those
specified in an @page rule that has no pseudo-class specified.
Properties specified in a :first @page rule override those specified
in :left (or :right) @page rules.
Note. Adding declarations to the :left or :right pseudo-class does not
influence whether the document comes out of the printer double- or
single-sided (which is outside the scope of this specification).
Note. Future versions of CSS may include other page pseudo-classes.
13.2.5 Content outside the page box
When formatting content in the page model, some content may end up
outside the page box. For example, an element whose 'white-space'
property has the value 'pre' may generate a box that is wider than the
page box. Also, when boxes are positioned absolutely, they may end up
in "inconvenient" locations. For example, images may be placed on the
edge of the page box or 100,000 inches below the page box.
A specification for the exact formatting of such elements lies outside
the scope of this document. However, we recommend that authors and
user agents observe the following general principles concerning
content outside the page box:
* Content should be allowed slightly beyond the page box to allow
pages to "bleed".
* User agents should avoid generating a large number of empty page
boxes to honor the positioning of elements (e.g., you don't want
to print 100 blank pages). Note, however, that generating a small
number of empty page boxes may be necessary to honor the 'left'
and 'right' values for 'page-break-before' and 'page-break-after'.
* Authors should not position elements in inconvenient locations
just to avoid rendering them. Instead:
+ To suppress box generation entirely, set the 'display'
property to 'none'.
+ To render a box invisible, use the 'visibility' property.
* User agents may handle boxes positioned outside the page box in
several ways, including discarding them or creating page boxes for
them at the end of the document.
13.3 Page breaks
The following sections explain page formatting in CSS2. Five
properties indicate where the user agent may or should break pages,
and on what page (left or right) the subsequent content should resume.
Each page break ends layout in the current page box and causes
remaining pieces of the document tree to be laid out in a new page
box.
13.3.1 Break before/after elements: 'page-break-before', 'page-break-after',
'page-break-inside'
'page-break-before'
Value: auto | always | avoid | left | right | inherit
Initial: auto
Applies to: block-level elements
Inherited: no
Percentages: N/A
Media: visual, paged
'page-break-after'
Value: auto | always | avoid | left | right | inherit
Initial: auto
Applies to: block-level elements
Inherited: no
Percentages: N/A
Media: visual, paged
'page-break-inside'
Value: avoid | auto | inherit
Initial: auto
Applies to: block-level elements
Inherited: yes
Percentages: N/A
Media: visual, paged
Values for these properties have the following meanings:
auto
Neither force nor forbid a page break before (after, inside)
the generated box.
always
Always force a page break before (after) the generated box.
avoid
Avoid a page break before (after, inside) the generated box.
left
Force one or two page breaks before (after) the generated box
so that the next page is formatted as a left page.
right
Force one or two page breaks before (after) the generated box
so that the next page is formatted as a right page.
A potential page break location is typically under the influence of
the parent element's 'page-break-inside' property, the
'page-break-after' property of the preceding element, and the
'page-break-before' property of the following element. When these
properties have values other than 'auto', the values 'always', 'left',
and 'right' take precedence over 'avoid'. See the section on allowed
page breaks for the exact rules on how these properties may force or
suppress a page break.
13.3.2 Using named pages: 'page'
'page'
Value: [ :left | :right ]? | auto
Initial: auto
Applies to: block-level elements
Inherited: yes
Percentages: N/A
Media: visual, paged
The 'page' property can be used to specify a particular type of page
where an element should be displayed.
By adding ':left' or ':right' the element can be forced to fall on a
left or right page as well.
This example will put all tables on a right-hand side landscape page
(named "rotated"):
@page rotated {size: landscape}
TABLE {page: rotated:right}
The 'page' property works as follows: If a block box with inline
content has a 'page' property that is different from the preceding
block box with inline content, then one or two page breaks are
inserted between them, and the boxes after the break are rendered onto
a page box of the named type. See "Forced page breaks" below.
In this example, the two tables are rendered on landscape pages
(indeed, on the same page, if they fit), and the page type "narrow" is
not used at all, despite having been set on the DIV:
@page narrow {size: 9cm 18cm}
@page rotated {size: landscape}
DIV {page: narrow}
TABLE {page: rotated}
with this document::
13.3.3 Breaks inside elements: 'orphans', 'widows', and 'page-break-inside'
'orphans'
Value: | inherit
Initial: 2
Applies to: block-level elements
Inherited: yes
Percentages: N/A
Media: visual, paged
'widows'
Value: | inherit
Initial: 2
Applies to: block-level elements
Inherited: yes
Percentages: N/A
Media: visual, paged
The 'orphans' property specifies the minimum number of lines of a
paragraph that must be left at the bottom of a page. The 'widows'
property specifies the minimum number of lines of a paragraph that
must be left at the top of a page. Examples of how they are used to
control page breaks are given below.
The 'page-break-inside' property can be used to turn off page breaking
inside an element completely, i.e., keep the whole element on one
page. The 'widows' and 'orphans' properties are not used if
'page-break-inside' is 'avoid'. However, if the element is larger than
the page, so that it has to be broken, then the 'page-break-inside'
property is ignored (treated as if it were 'auto') and page breaks are
determined using the 'widows' and 'orphans' properties.
For information about paragraph formatting, please consult the section
on line boxes.
13.3.4 Allowed page breaks
In the normal flow, page breaks can occur at the following places:
1. In the vertical margin between block boxes. When a page break
occurs here, the actual values of the relevant 'margin-top' and
'margin-bottom' properties are set to '0'.
2. Between line boxes inside a block box.
These breaks are subject to the following rules:
* Rule A: Breaking at (1) is allowed only if the 'page-break-after'
and 'page-break-before' properties of all the elements generating
boxes that meet at this margin allow it, which is when at least
one of them has the value 'always', 'left', or 'right', or when
all of them are 'auto'.
* Rule B: However, if all of them are 'auto' and the nearest common
ancestor of all the elements has a 'page-break-inside' value of
'avoid', then breaking here is not allowed.
* Rule C: Breaking at (2) is allowed only if the number of line
boxes between the break and the start of the enclosing block box
is 'orphans' or more, and the number of line boxes between the
break and the end of the box is 'widows' or more.
* Rule D: In addition, breaking at (2) is allowed only if the
'page-break-inside' property is 'auto'.
If the above doesn't provide enough break points to keep content from
overflowing the page boxes, then rules B and D are dropped in order to
find additional breakpoints.
If that still does not lead to sufficient break points, rules A and C
are dropped as well, to find still more break points.
Page breaks cannot occur inside boxes that are absolutely-positioned.
13.3.5 Forced page breaks
A page break must occur at (1) if, among the 'page-break-after' and
'page-break-before' properties of all the elements generating boxes
that meet at this margin, there is at least one with the value
'always', 'left', or 'right'.
A page break must also occur at (1) if the last line box above this
margin and the first one below it do not have the same value for
'page'.
13.3.6 "Best" page breaks
CSS2 does not define which of a set of allowed page breaks must be
used; CSS2 does not forbid a user agent from breaking at every
possible break point, or not to break at all. But CSS2 does recommend
that user agents observe the following heuristics (while recognizing
that they are sometimes contradictory):
* Break as few times as possible.
* Make all pages that don't end with a forced break appear to have
about the same height.
* Avoid breaking inside a block that has a border.
* Avoid breaking inside a table.
* Avoid breaking inside a floating element
Suppose, for example, that the style sheet contains 'orphans : 4',
'widows : 2', and there are 20 lines (line boxes) available at the
bottom of the current page:
* If a paragraph at the end of the current page contains 20 lines or
fewer, it should be placed on the current page.
* If the paragraph contains 21 or 22 lines, the second part of the
paragraph must not violate the 'widows' constraint, and so the
second part must contain exactly two lines
* If the paragraph contains 23 lines or more, the first part should
contain 20 lines and the second part the remaining lines.
Now suppose that 'orphans' is '10', 'widows' is '20', and there are 8
lines available at the bottom of the current page:
* If a paragraph at the end of the current page contains 8 lines or
fewer, it should be placed on the current page.
* If the paragraph contains 9 lines or more, it cannot be split
(that would violate the orphan constraint), so it should move as a
block to the next page.
13.4 Cascading in the page context
Declarations in the page context obey the cascade just like normal
CSS2 declarations.
Consider the following example:
@page {
margin-left: 3cm;
}
@page :left {
margin-left: 4cm;
}
Due to the higher specificity of the pseudo-class selector, the left
margin on left pages will be '4cm' and all other pages (i.e., the
right pages) will have a left margin of '3cm'.
_________________________________________________________________
_________________________________________________________________
14 Colors and Backgrounds
Contents
* 14.1 Foreground color: the 'color' property
* 14.2 The background
+ 14.2.1 Background properties: 'background-color',
'background-image', 'background-repeat',
'background-attachment', 'background-position', and
'background'
* 14.3 Gamma correction
CSS properties allow authors to specify the foreground color and
background of an element. Backgrounds may be colors or images.
Background properties allow authors to position the image, repeat it,
and declare whether it should be fixed with respect to the viewport or
scrolled along with the document.
See the section on color units for the syntax of valid color values.
14.1 Foreground color: the 'color' property
'color'
Value: | inherit
Initial: depends on user agent
Applies to: all elements
Inherited: yes
Percentages: N/A
Media: visual
This property describes the foreground color of an element's text
content. There are different ways to specify red:
EM { color: red } /* predefined color name */
EM { color: rgb(255,0,0) } /* RGB range 0-255 */
14.2 The background
Authors may specify the background of an element (i.e., its rendering
surface) as either a color or an image. In terms of the box model,
"background" refers to the background of the content and the padding
area. Border colors and styles are set with the border properties.
Margins are always transparent so the background of the parent box
always shines through.
Background properties are not inherited, but the parent box's
background will shine through by default because of the initial
'transparent' value on 'background-color'.
The background of the box generated by the root element covers the
entire canvas.
For HTML documents, however, we recommend that authors specify the
background for the BODY element rather than the HTML element. User
agents should observe the following precedence rules to fill in the
background: if the value of the 'background' property for the HTML
element is different from 'transparent' then use it, else use the
value of the 'background' property for the BODY element. If the
resulting value is 'transparent', the rendering is undefined.
According to these rules, the canvas underlying the following HTML
document will have a "marble" background:
Setting the canvas background
My background is marble.
14.2.1 Background properties: 'background-color', 'background-image',
'background-repeat', 'background-attachment', 'background-position', and
'background'
'background-color'
Value: | transparent | inherit
Initial: transparent
Applies to: all elements
Inherited: no
Percentages: N/A
Media: visual
This property sets the background color of an element, either a
value or the keyword 'transparent', to make the underlying
colors shine through.
H1 { background-color: #F00 }
'background-image'
Value: | none | inherit
Initial: none
Applies to: all elements
Inherited: no
Percentages: N/A
Media: visual
This property sets the background image of an element. When setting a
background image, authors should also specify a background color that
will be used when the image is unavailable. When the image is
available, it is rendered on top of the background color. (Thus, the
color is visible in the transparent parts of the image).
The values are , to specify the image, or 'none', when no image
is used.
Example:
BODY { background-image: url(marble.gif) }
P { background-image: none }
'background-repeat'
Value: repeat | repeat-x | repeat-y | no-repeat | inherit
Initial: repeat
Applies to: all elements
Inherited: no
Percentages: N/A
Media: visual
If a background image is specified, this property specifies whether
the image is repeated (tiled), and how. All tiling covers the content
and padding areas of a box. Values have the following meanings:
repeat
The image is repeated both horizontally and vertically.
repeat-x
The image is repeated horizontally only.
repeat-y
The image is repeated vertically only.
no-repeat
The image is not repeated: only one copy of the image is drawn.
Example:
BODY {
background: red url(pendant.gif);
background-repeat: repeat-y;
background-position: center;
}
A centered background image, with copies repeated up and down the
padding and content areas.
One copy of the background image is centered, and other copies are put
above and below it to make a vertical band behind the element.
'background-attachment'
Value: scroll | fixed | inherit
Initial: scroll
Applies to: all elements
Inherited: no
Percentages: N/A
Media: visual
If a background image is specified, this property specifies whether it
is fixed with regard to the viewport ('fixed') or scrolls along with
the document ('scroll').
Even if the image is fixed, it is still only visible when it is in the
background or padding area of the element. Thus, unless the image is
tiled ('background-repeat: repeat'), it may be invisible.
This example creates an infinite vertical band that remains "glued" to
the viewport when the element is scrolled.
BODY {
background: red url(pendant.gif);
background-repeat: repeat-y;
background-attachment: fixed;
}
User agents may treat 'fixed' as 'scroll'. However, it is recommended
they interpret 'fixed' correctly, at least for the HTML and BODY
elements, since there is no way for an author to provide an image only
for those browsers that support 'fixed'. See the section on
conformance for details.
'background-position'
Value: [ [ | ]{1,2} | [ [top | center |
bottom] || [left | center | right] ] ] | inherit
Initial: 0% 0%
Applies to: block-level and replaced elements
Inherited: no
Percentages: refer to the size of the element itself
Media: visual
If a background image has been specified, this property specifies its
initial position. Values have the following meanings:
With a value pair of '0% 0%', the upper left corner of the
image is aligned with the upper left corner of the box's
padding edge. A value pair of '100% 100%' places the lower
right corner of the image in the lower right corner of the box.
With a value pair of '14% 84%', the point 14% across and 84%
down the image is to be placed at the point 14% across and 84%
down the box.
With a value pair of '2cm 2cm', the upper left corner of the
image is placed 2cm to the right and 2cm below the upper left
corner of the box.
top left and left top
Same as '0% 0%'.
top, top center, and center top
Same as '50% 0%'.
right top and top right
Same as '100% 0%'.
left, left center, and center left
Same as '0% 50%'.
center and center center
Same as '50% 50%'.
right, right center, and center right
Same as '100% 50%'.
bottom left and left bottom
Same as '0% 100%'.
bottom, bottom center, and center bottom
Same as '50% 100%'.
bottom right and right bottom
Same as '100% 100%'.
If only one percentage or length value is given, it sets the
horizontal position only, the vertical position will be 50%. If two
values are given, the horizontal position comes first. Combinations of
length and percentage values are allowed, (e.g., '50% 2cm'). Negative
positions are allowed. Keywords cannot be combined with percentage
values or length values (all possible combinations are given above).
Examples:
BODY { background: url(banner.jpeg) right top } /* 100% 0% */
BODY { background: url(banner.jpeg) top center } /* 50% 0% */
BODY { background: url(banner.jpeg) center } /* 50% 50% */
BODY { background: url(banner.jpeg) bottom } /* 50% 100% */
If the background image is fixed within the viewport (see the
'background-attachment' property), the image is placed relative to the
viewport instead of the element's box. For example,
BODY {
background-image: url(logo.png);
background-attachment: fixed;
background-position: 100% 100%;
}
In the example above, the image is placed in the lower-right corner of
the viewport.
'background'
Value: [<'background-color'> || <'background-image'> ||
<'background-repeat'> || <'background-attachment'> ||
<'background-position'>] | inherit
Initial: not defined for shorthand properties
Applies to: all elements
Inherited: no
Percentages: allowed on 'background-position'
Media: visual
The 'background' property is a shorthand property for setting the
individual background properties (i.e., 'background-color',
'background-image', 'background-repeat', 'background-attachment' and
'background-position') at the same place in the style sheet.
The 'background' property always sets all the individual background
properties.
In the first rule of the following example, only a value for
'background-color' has been given and the other individual properties
are set to their initial value. In the second rule, all individual
properties have been specified.
BODY { background: red }
P { background: url(chess.png) gray 50% repeat fixed }
14.3 Gamma correction
For information about gamma issues, please consult the the Gamma
Tutorial in the PNG specification ([PNG10]).
In the computation of gamma correction, UAs displaying on a CRT may
assume an ideal CRT and ignore any effects on apparent gamma caused by
dithering. That means the minimal handling they need to do on current
platforms is:
PC using MS-Windows
none
Unix using X11
none
Mac using QuickDraw
apply gamma 1.39 [ICC32] (ColorSync-savvy applications may
simply pass the sRGB ICC profile to ColorSync to perform
correct color correction)
SGI using X
apply the gamma value from /etc/config/system.glGammaVal (the
default value being 1.70; applications running on Irix 6.2 or
above may simply pass the sRGB ICC profile to the color
management system)
NeXT using NeXTStep
apply gamma 2.22
"Applying gamma" means that each of the three R, G and B must be
converted to R'=Rgamma, G'=Ggamma, B'=Bgamma, before handing to the
OS.
This may rapidly be done by building a 256-element lookup table once
per browser invocation thus:
for i := 0 to 255 do
raw := i / 255.0;
corr := pow (raw, gamma);
table[i] := trunc (0.5 + corr * 255.0)
end
which then avoids any need to do transcendental math per color
attribute, far less per pixel.
_________________________________________________________________
_________________________________________________________________
15 Fonts
Contents
* 15.1 Introduction
* 15.2 Font specification
+ 15.2.1 Font specification properties
+ 15.2.2 Font family: the 'font-family' property
+ 15.2.3 Font styling: the 'font-style', 'font-variant',
'font-weight' and 'font-stretch' properties
+ 15.2.4 Font size: the 'font-size' and 'font-size-adjust'
properties
+ 15.2.5 Shorthand font property: the 'font' property
+ 15.2.6 Generic font families
o serif
o sans-serif
o cursive
o fantasy
o monospace
* 15.3 Font selection
+ 15.3.1 Font Descriptions and @font-face
+ 15.3.2 Descriptors for Selecting a Font: 'font-family',
'font-style', 'font-variant', 'font-weight', 'font-stretch'
and 'font-size'
+ 15.3.3 Descriptors for Font Data Qualification:
'unicode-range'
+ 15.3.4 Descriptor for Numeric Values: 'units-per-em'
+ 15.3.5 Descriptor for Referencing: 'src'
+ 15.3.6 Descriptors for Matching: 'panose-1', 'stemv',
'stemh', 'slope', 'cap-height', 'x-height', 'ascent', and
'descent'
+ 15.3.7 Descriptors for Synthesis: 'widths', 'bbox' and
'definition-src'
+ 15.3.8 Descriptors for Alignment: 'baseline', 'centerline',
'mathline', and 'topline'
+ 15.3.9 Examples
* 15.4 Font Characteristics
+ 15.4.1 Introducing Font Characteristics
+ 15.4.2 Full font name
+ 15.4.3 Coordinate units on the em square
+ 15.4.4 Central Baseline
+ 15.4.5 Font Encoding
+ 15.4.6 Font family name
+ 15.4.7 Glyph widths
+ 15.4.8 Horizontal stem width
+ 15.4.9 Height of uppercase glyphs
+ 15.4.10 Height of lowercase glyphs
+ 15.4.11 Lower Baseline
+ 15.4.12 Mathematical Baseline
+ 15.4.13 Maximal bounding box
+ 15.4.14 Maximum unaccented height
+ 15.4.15 Maximum unaccented depth
+ 15.4.16 Panose-1 number
+ 15.4.17 Range of ISO 10646 characters
+ 15.4.18 Top Baseline
+ 15.4.19 Vertical stem width
+ 15.4.20 Vertical stroke angle
* 15.5 Font matching algorithm
+ 15.5.1 Mapping font weight values to font names
+ 15.5.2 Examples of font matching
15.1 Introduction
When a document's text is to be displayed visually, characters
(abstract information elements) must be mapped to abstract glyphs. One
or more characters may be depicted by one or more abstract glyphs, in
a possibly context-dependent fashion. A glyph is the actual artistic
representation of an abstract glyph, in some typographic style, in the
form of outlines or bitmaps that may be drawn on the screen or paper.
A font is a set of glyphs, all observing the same basic motif
according to design, size, appearance, and other attributes associated
with the entire set, and a mapping from characters to abstract glyphs.
A visual user agent must address the following issues before actually
rendering a character:
* Is there, directly or by inheritance, a font specified for this
character?
* Does the user agent have this font available?
* If so, what glyph(s) does this character or sequence of characters
map to?
* If not, what should be done? Should a different font be
substituted? Can the font be synthesized? Can it be retrieved from
the Web?
In both CSS1 and CSS2, authors specify font characteristics via a
series of font properties.
How the user agent handles with properties, when there is no matching
font on the client, has expanded between CSS1 and CSS2. In CSS1, all
fonts were assumed to be present on the client system and were
identified solely by name. Alternate fonts could be specified through
the properties, but beyond that, user agents had no way to propose
other fonts to the user (even stylistically similar fonts that the
user agent had available) other than generic default fonts.
CSS2 changes all that, and allows much greater liberty for:
* style sheet authors, to describe the fonts they want to be used
* user agents, in selecting a font when an author's requested font
is not immediately available.
CSS2 improves client-side font matching, enables font synthesis and
progressive rendering, and enables fonts to be downloaded over the
Web.
In the CSS2 font model, as in CSS1, each user agent has a "font
database" at its disposition. CSS1 referred to this database but gave
no details about what was in it. CSS2 defines the information in that
database and allows style sheet authors to contribute to it. When
asked to display a character with a particular font, the user agent
first identifies the font in the database that "best fits" the
specified font (according to the font matching algorithm) Once it has
identified a font, it retrieves the font data locally or from the Web,
and may display the character using those glyphs.
In light of this model, we have organized the specification into two
sections. The first concerns the font specification mechanism, whereby
authors specify which fonts they would like to have used. The second
concerns the font selection mechanism, whereby the client's user agent
identifies and loads a font that best fits the author's specification.
How the user agent constructs the font database lies outside the scope
of this specification since the database's implementation depends on
such factors as the operating system, the windowing system, and the
client.
15.2 Font specification
The first phase of the CSS font mechanism concerns how style sheet
authors specify which fonts should be used by a user agent. At first,
it seem that the obvious way to specify a font is by it's name, a
single string - which appears to be separated into distinct parts; for
example "BT Swiss 721 Heavy Italic".
Unfortunately, there exists no well-defined and universally accepted
taxonomy for classifying fonts based on their names, and terms that
apply to one font family name may not be appropriate for others. For
example, the term 'italic' is commonly used to label slanted text, but
slanted text may also be labeled Oblique, Slanted, Incline, Cursive or
Kursiv. Similarly, font names typically contain terms that describe
the "weight" of a font. The primary role of these names is to
distinguish faces of differing darkness within a single font family.
There is no accepted, universal meaning to these weight names and
usage varies widely. For example a font that you might think of as
being bold might be described as being Regular, Roman, Book, Medium,
Semi- or Demi-Bold, Bold, or Black, depending on how black the
"normal" face of the font is within the design.
This lack of systematic naming makes it impossible, in the general
case, to generate a modified font face name that differs in a
particular way, such as being bolder.
Because of this, CSS uses a different model. Fonts are requested not
through a single font name but through setting a series of font
properties. These property values form the basis of the user agent's
font selection mechanism. The font properties can be individually
modified, for example to increase the boldness, and the new set of
font property values will then be used to select from the font
database again. The result is an increase in regularity for style
sheet authors and implementors, and an increase in robustness.
15.2.1 Font specification properties
CSS2 specifies fonts according to these characteristics:
Font family
The font family specifies which font family is to be used to
render the text. A font family is a group of fonts,designed to
be used in combination and exhibiting similarities in design.
One member of the family may be italic, another bold, another
condensed or using small caps. Font family names include
Helvetica, "New Century Schoolbook", and "Kyokasho ICA L". Font
family names are not restricted to Latin characters. Font
families may be grouped into different categories: those with
or without serifs, those whose characters are or are not
proportionally spaced, those that resemble handwriting, those
that are fantasy fonts, etc.
Font style
The font style specifies whether the text is to be rendered
using a normal, italic, or oblique face. Italic is a more
cursive companion face to the normal face, but not so cursive
as to make it a script face. Oblique is a slanted form of the
normal face, and is more commonly used as a companion face to
sans-serif. This definition avoids having to label slightly
slanted normal faces as oblique, or normal Greek faces as
italic.
Font variant
The font variant indicates whether the text is to be rendered
using the normal glyphs for lowercase characters or using
small-caps glyphs for lowercase characters. A particular font
may contain only normal, only small-caps, or both types of
glyph; this property is used to request an appropriate font
and, if the font contains both variants, the appropriate
glyphs.
Font weight
The font weight refers to the boldness or lightness of the
glyphs used to render the text, relative to other fonts in the
same font family.
Font stretch
The font stretch indicates the desired amount of condensing or
expansion in the glyphs used to render the text, relative to
other fonts in the same font family.
Font size
The font size refers to the size of the font from baseline to
baseline, when set solid (in CSS terms, this is when the
'font-size' and 'line-height' properties have the same value).
On all properties except 'font-size', 'em' and 'ex' length values
refer to the font size of the current element. For 'font-size', these
length units refer to the font size of the parent element. Please
consult the section on length units for more information.
These font properties in CSS are used to describe the desired
appearance of text in the document. The font descriptors, in contrast,
are used to describe the characteristics of fonts, so that a suitable
font can be chosen to create the desired appearance. For information
about the classification of fonts, please consult the section on font
descriptors.
15.2.2 Font family: the 'font-family' property
'font-family'
Value: [[ | ],]*
[ | ] | inherit
Initial: depends on user agent
Applies to: all elements
Inherited: yes
Percentages: N/A
Media: visual
This property specifies a prioritized list of font family names and/or
generic family names. To deal with the problem that a single font may
not contain glyphs to display all the characters in a document, or
that not all fonts are available on all systems, this property allows
authors to specify a list of fonts, all of the same style and size,
that are tried in sequence to see if they contain a glyph for a
certain character. This list is called a font set.
For example, text that contains English words mixed with mathematical
symbols may need a font set of two fonts, one containing Latin letters
and digits, the other containing mathematical symbols. Here is an
example of a font set suitable for a text that is expected to contain
text with Latin characters, Japanese characters, and mathematical
symbols:
BODY { font-family: Baskerville, "Heisi Mincho W3", Symbol, serif }
The glyphs available in the "Baskerville" font (a font which covers
only Latin characters) will be taken from that font, Japanese glyphs
will be taken from "Heisi Mincho W3", and the mathematical symbol
glyphs will come from "Symbol". Any others will come from the generic
font family 'serif'.
The generic font family will be used if one or more of the other fonts
in a font set is unavailable. Although many fonts provide the "missing
character" glyph, typically an open box, as its name implies this
should not be considered a match except for the last font in a font
set.
There are two types of font family names:
The name of a font family of choice. In the previous example,
"Baskerville", "Heisi Mincho W3", and "Symbol" are font
families. Font family names containing whitespace should be
quoted. If quoting is omitted, any whitespace characters before
and after the font name are ignored and any sequence of
whitespace characters inside the font name is converted to a
single space.
The following generic families are defined: 'serif',
'sans-serif', 'cursive', 'fantasy' and 'monospace'. Please see
the section on generic font families for descriptions of these
families. Generic font family names are keywords and therefore
must not be quoted.
Authors are encouraged to offer a generic font family as a last
alternative, for improved robustness.
For example:
Font test
Test
What's up, Doc?
The richer selector syntax of CSS2 may be used to create
language-sensitive typography. For example, some Chinese and Japanese
characters are unified to have the same Unicode codepoint, although
the abstract glyphs are not the same in the two languages.
*:lang(ja-jp) { font: 900 14pt/16pt "Heisei Mincho W9", serif }
*:lang(zh-tw) { font: 800 14pt/16.5pt "Li Sung", serif }
This selects any element which has the given language - Japanese or
Traditional Chinese - and requests the appropriate font.
15.2.3 Font styling: the 'font-style', 'font-variant', 'font-weight' and
'font-stretch' properties
'font-style'
Value: normal | italic | oblique | inherit
Initial: normal
Applies to: all elements
Inherited: yes
Percentages: N/A
Media: visual
The 'font-style' property requests normal (sometimes referred to as
"roman" or "upright"), italic, and oblique faces within a font family.
Values have the following meanings:
normal
Specifies a font that is classified as 'normal' in the UA's
font database.
oblique
Specifies a font that is classified as 'oblique' in the UA's
font database. Fonts with Oblique, Slanted or Incline in their
names will typically be labeled 'oblique' in the font database.
A font that is labeled 'oblique' in the UA's font database may
actually have been generated by electronically slanting a
normal font.
italic
Specifies a font that is classified as 'italic' in the UA's
font database, or, if that is not available, one labeled
'oblique'. Fonts with Italic, Cursive or Kursiv in their names
will typically be labeled 'italic'.
In this example, normal text in an H1, H2, or H3 element will be
displayed with an italic font. However, emphasized text (EM) within an
H1 will appear in a normal face.
H1, H2, H3 { font-style: italic }
H1 EM { font-style: normal }
'font-variant'
Value: normal | small-caps | inherit
Initial: normal
Applies to: all elements
Inherited: yes
Percentages: N/A
Media: visual
In a small-caps font, the glyphs for lowercase letters look similar to
the uppercase ones, but in a smaller size and with slightly different
proportions. The 'font-variant' property requests such a font for
bicameral (having two cases, as with Latin script). This property has
no visible effect for scripts which are unicameral (having only one
case, as with most of the world's writing systems). Values have the
following meanings:
normal
Specifies a font that is not labeled as a small-caps font.
small-caps
Specifies a font that is labeled as a small-caps font. If a
genuine small-caps font is not available, user agents should
simulate a small-caps font, for example by taking a normal font
and replacing the lowercase letters by scaled uppercase
characters. As a last resort, unscaled uppercase letter glyphs
in a normal font may replace glyphs in a small-caps font so
that the text appears in all uppercase letters.
The following example results in an H3 element in small-caps, with
emphasized words (EM) in oblique small-caps:
H3 { font-variant: small-caps }
EM { font-style: oblique }
Insofar as this property causes text to be transformed to uppercase,
the same considerations as for 'text-transform' apply.
'font-weight'
Value: normal | bold | bolder | lighter | 100 | 200 | 300 |
400 | 500 | 600 | 700 | 800 | 900 | inherit
Initial: normal
Applies to: all elements
Inherited: yes
Percentages: N/A
Media: visual
The 'font-weight' property specifies the weight of the font. Values
have the following meanings:
100 to 900
These values form an ordered sequence, where each number
indicates a weight that is at least as dark as its predecessor.
normal
Same as '400'.
bold
Same as '700'.
bolder
Specifies the next weight that is assigned to a font that is
darker than the inherited one. If there is no such weight, it
simply results in the next darker numerical value (and the font
remains unchanged), unless the inherited value was '900', in
which case the resulting weight is also '900'.
lighter
Specifies the next weight that is assigned to a font that is
lighter than the inherited one. If there is no such weight, it
simply results in the next lighter numerical value (and the
font remains unchanged), unless the inherited value was '100',
in which case the resulting weight is also '100'.
P { font-weight: normal } /* 400 */
H1 { font-weight: 700 } /* bold */
BODY { font-weight: 400 }
STRONG { font-weight: bolder } /* 500 if available */
Child elements inherit the computed value of the weight.
'font-stretch'
Value: normal | wider | narrower | ultra-condensed |
extra-condensed | condensed | semi-condensed | semi-expanded |
expanded | extra-expanded | ultra-expanded | inherit
Initial: normal
Applies to: all elements
Inherited: yes
Percentages: N/A
Media: visual
The 'font-stretch' property specifies between normal, condensed and
extended faces within a font family. Absolute keyword values have the
following ordering, from narrowest to widest :
1. ultra-condensed
2. extra-condensed
3. condensed
4. semi-condensed
5. normal
6. semi-expanded
7. expanded
8. extra-expanded
9. ultra-expanded
The relative keyword 'wider' sets the value to the next more expanded
value more than the inherited value (while not increasing it above
ultra-expanded); the relative keyword 'narrower' sets the value to the
next more condensed value than the inherited value (while not
decreasing it below ultra-condensed).
15.2.4 Font size: the 'font-size' and 'font-size-adjust' properties
'font-size'
Value: | | |
| inherit
Initial: medium
Applies to: all elements
Inherited: yes, the computed value is inherited
Percentages: relative to parent element's font size
Media: visual
This property describes the size of the font when set solid. Values
have the following meanings:
An keyword refers to an entry in a table of
font sizes computed and kept by the user agent. Possible values
are:
[ xx-small | x-small | small | medium | large | x-large |
xx-large ]
On a computer screen a scaling factor of 1.2 is suggested
between adjacent indexes; if the 'medium' font is 12pt, the
'large' font could be 14.4pt. Different media may need
different scaling factors. Also, the user agent should take the
quality and availability of fonts into account when computing
the table. The table may be different from one font family to
another.
Note: In CSS1, the suggested scaling factor between adjacent
indexes was 1.5 which user experience proved to be too large.
A keyword is interpreted relative to the table
of font sizes and the font size of the parent element. Possible
values are:
[ larger | smaller ]
For example, if the parent element has a font size of 'medium',
a value of 'larger' will make the font size of the current
element be 'large'. If the parent element's size is not close
to a table entry, the user agent is free to interpolate between
table entries or round off to the closest one. The user agent
may have to extrapolate table values if the numerical value
goes beyond the keywords.
A length value specifies an absolute font size (that is
independent of the user agent's font table). Negative lengths
are illegal.
A percentage value specifies an absolute font size relative to
the parent element's font size. Use of percentage values, or
values in 'em's, leads to more robust and cascadable style
sheets.
The actual value of this property may differ from the computed value
due a numerical value on 'font-size-adjust' and the unavailability of
certain font sizes.
Child elements inherit the computed 'font-size' value. Otherwise, the
effect of 'font-size-adjust' would have been applied multiple times.
Examples:
P { font-size: 12pt; }
BLOCKQUOTE { font-size: larger }
EM { font-size: 150% }
EM { font-size: 1.5em }
'font-size-adjust'
Value: | none | inherit
Initial: none
Applies to: all elements
Inherited: yes
Percentages: relative to parent element's font size
Media: visual
In bicameral scripts, the subjective apparent size (and general
character of a font on screen) is less dependent on its 'font-size'
than on the value of its 'x-height', or, more usefully, on the ratio
of these two values, called the z value (font size divided by
x-height). The lower the z value, the more likely it is that a font at
smaller em sizes will be legible. Inversely, faces with a higher z
value will become illegible more rapidly below a given threshold size
than faces with a lower z value. Straightforward font substitution
that relies on font size alone may lead to illegible characters.
For example, the popular font Verdana has a z value of 1.72; in an
instance of Verdana with 'font-size' 100 points, the 'x-height' is 58
pt (100/58=1.72). For comparison, Times New Roman has a z value of
2.17. As the z value increases, a font for a bicameral script becomes
less legible at a given point size.
This property allows authors to specify a z value for an element that
preserves the 'x-height' of the first choice substitute font. Values
have the following meanings:
none
Do not preserve the font's x-height.
Specifies the z value. This number refers to the 'z' value of
the "first choice" font. The scaling factor for available fonts
is computed according to the following formula:
a(z'/z) = b
where:
a = 'font-size' of first-choice font
z' = z of available font
b = 'font-size' to apply to available font
For example, if 14px Verdana (with a z value of 1.72) was unavailable
and the generic sans-serif on a particular platform had a z value of
2.09, the size of the sans-serif would be 14 times (2.09/1.72) = 17px.
Font size adjustments are based on the computed value of 'font-size'.
The first image below shows several typefaces as rasterized on a
Macintosh at 12-point, together with their z values. No matter what
the typographical family (or nominal base size, unit, or platform),
faces with lower z values look bigger than those with higher z values.
Faces with very high z values are illegible at the size shown.
Comparison of 12 point fonts
The next image shows the results of 'font-size-adjust' with the fonts
shown in the previous image. These fonts' em sizes range all the way
up to 25-point, but appear subjectively to be about as large as
12-point Verdana, whose z value served as the base for scaling. As
adjusted, the legibility characteristics of these faces on screen are
nearly linear across faces. Note that 'font-size-adjust' tends to
stabilize the horizontal metrics of lines, as well.
Comparison of font-adjusted fonts
15.2.5 Shorthand font property: the 'font' property
'font'
Value: [ [ <'font-style'> || <'font-variant'> ||
<'font-weight'> ]? <'font-size'> [ / <'line-height'> ]?
<'font-family'> ] | caption | icon | menu | message-box |
small-caption | status-bar | inherit
Initial: see individual properties
Applies to: all elements
Inherited: yes
Percentages: allowed on 'font-size' and 'line-height'
Media: visual
The 'font' property is, except as described below, a shorthand
property for setting 'font-style', 'font-variant', 'font-weight',
'font-size', 'line-height', and 'font-family', at the same place in
the style sheet. The syntax of this property is based on a traditional
typographical shorthand notation to set multiple properties related to
fonts.
All font related properties are first reset to their initial values,
including those listed in the preceding paragraph plus 'font-stretch'
and 'font-size-adjust'. Then, those properties that are given explicit
values in the 'font' shorthand are set to those values. For a
definition of allowed and initial values, see the previously defined
properties. For reasons of backwards compatibility, it is not possible
to set 'font-stretch' and 'font-size-adjust' to other than their
initial values using the 'font' shorthand property; instead, set the
individual properties.
Examples:
P { font: 12pt/14pt sans-serif }
P { font: 80% sans-serif }
P { font: x-large/110% "new century schoolbook", serif }
P { font: bold italic large Palatino, serif }
P { font: normal small-caps 120%/120% fantasy }
P { font: oblique "Helvetica Nue", serif; font-stretch: condensed }
In the second rule, the font size percentage value ('80%') refers to
the font size of the parent element. In the third rule, the line
height percentage ('110%') refers to the font size of the element
itself.
The first three rules do not specify the 'font-variant' and
'font-weight' explicitly, so these properties receive their initial
values ('normal'). Notice that the font family name "new century
schoolbook", which contains spaces, is enclosed in quotes. The fourth
rule sets the 'font-weight' to 'bold', the 'font-style' to 'italic',
and implicitly sets 'font-variant' to 'normal'.
The fifth rule sets the 'font-variant' ('small-caps'), the 'font-size'
(120% of the parent's font size), the 'line-height' (120% of the font
size) and the 'font-family' ('fantasy'). It follows that the keyword
'normal' applies to the two remaining properties: 'font-style' and
'font-weight'.
The sixth rule sets the 'font-style' and 'font-family', the other font
properties being set to their initial values; it then sets
'font-stretch' to 'condensed' since it cannot be set to that value
using the 'font' shorthand property.
The following values refer to system fonts:
caption
The font used for captioned controls (e.g. buttons, drop-downs,
etc.).
icon
The font used to label icons.
menu
The font used in menus (e.g., dropdown menus and menu lists).
message-box
The font used in dialog boxes.
small-caption
The font used for labeling small controls.
status-bar
The font used in window status bars.
System fonts may only be set as a whole; that is, the font family,
size, weight, style, etc. are all set at the same time.These values
may then be altered individually if desired. If no font with the
indicated characteristics exists on a given platform, the user agent
should either intelligently substitute (e.g., a smaller version of the
'caption' font might be used for the 'smallcaption' font), or
substitute a user agent default font. As for regular fonts, if, for a
system font, any of the individual properties are not part of the
operating system's available user preferences, those properties should
be set to their initial values.
That is why this property is "almost" a shorthand property: system
fonts can only be specified with this property, not with 'font-family'
itself, so 'font' allows authors to do more than the sum of its
subproperties. However, the individual properties such as
'font-weight' are still given values taken from the system font, which
can be independently varied.
Example:
BUTTON { font: 300 italic 1.3em/1.7em "FB Armada", sans-serif }
BUTTON P { font: menu }
BUTTON P EM { font-weight: bolder }
If the font used for dropdown menus on a particular system happened to
be 9-point Charcoal, with a weight of 600, then P elements which were
descendants of BUTTON would be displayed as if this rule were in
effect (the values for the remaining properties being taken from the
initial values):
BUTTON P {
font-style: normal;
font-variant: normal;
font-weight: 600;
font-size: 9pt;
line-height: normal;
font-family: Charcoal
}
15.2.6 Generic font families
Generic font families are a fallback mechanism, a means of preserving
some of the style sheet writer's intent in the worst case when none of
the specified fonts can be selected. For optimum typographic control,
particular named fonts should be used in style sheets.
All five generic font families are defined to exist in all CSS
implementations (they need not necessarily map to five distinct actual
fonts, in all cases). User agents should provide reasonable default
choices for the generic font families, which express the
characteristics of each family as well as possible within the limits
allowed by the underlying technology.
User agents are encouraged to allow users to select alternative
choices for the generic fonts.
serif
Glyphs of serif fonts, as the term is used in CSS, have finishing
strokes, flared or tapering ends, or have actual serifed endings
(including slab serifs). Serif fonts are typically proportionately
spaced. They often display a greater variation between thick and thin
strokes than fonts from the 'sans-serif' generic font family. CSS uses
the term 'serif' to apply to a font for any script, although other
names may be more familiar for particular scripts, such as Mincho
(Japanese), Sung or Song (Chinese), Totum or Kodig (Korean), and any
font which is so described may be used to represent the generic
'serif' family.
Examples of fonts that fit this description include:
Latin fonts Times New Roman, Bodoni, Garamond, Minion Web, ITC Stone
Serif, MS Georgia, Bitstream Cyberbit
Greek fonts Bitstream Cyberbit
Cyrillic fonts Adobe Minion Cyrillic, Excelcior Cyrillic Upright,
Monotype Albion 70, Bitstream Cyberbit, ER Bukinst
Hebrew fonts New Peninim, Raanana, Bitstream Cyberbit
Japanese fonts Ryumin Light-KL, Kyokasho ICA, Futo Min A101
Arabic fonts Bitstream Cyberbit
Cherokee fonts Lo Cicero Cherokee
sans-serif
Glyphs in sans-serif fonts, as the term is used in CSS, have stroke
endings that are plain -- without any flaring, cross stroke, or other
ornamentation. Sans-serif fonts are typically proportionately spaced.
They often have little variation between thick and thin strokes,
compared to fonts from the 'serif' family. CSS uses the term
'sans-serif' to apply to a font for any script, although other names
may be more familiar for particular scripts, such as Gothic
(Japanese), Kai (Chinese), Pathang (Korean), and any font which is so
described may be used to represent the generic 'sans-serif' family.
Examples of fonts that fit this description include:
Latin fonts MS Trebuchet, ITC Avant Garde Gothic, MS Arial, MS
Verdana, Univers, Futura, ITC Stone Sans, Gill Sans, Akzidenz Grotesk,
Helvetica
Greek fonts Attika, Typiko New Era, MS Tahoma, Monotype Gill Sans 571,
Helvetica Greek
Cyrillic fonts Helvetica Cyrillic, ER Univers, Lucida Sans Unicode,
Bastion
Hebrew fonts Arial Hebrew, MS Tahoma
Japanese fonts Shin Go, Heisei Kaku Gothic W5
Arabic fonts MS Tahoma
cursive
Glyphs in cursive fonts, as the term is used in CSS, generally have
either joining strokes or other cursive characteristics beyond those
of italic typefaces. The glyphs are partially or completely connected,
and the result looks more like handwritten pen or brush writing than
printed letterwork. Fonts for some scripts, such as Arabic, are almost
always cursive. CSS uses the term 'cursive' to apply to a font for any
script, although other names such as Chancery, Brush, Swing and Script
are also used in font names.
Examples of fonts that fit this description include:
Latin fonts Caflisch Script, Adobe Poetica, Sanvito, Ex Ponto, Snell
Roundhand, Zapf-Chancery
Cyrillic fonts ER Architekt
Hebrew fonts Corsiva
Arabic fonts DecoType Naskh, Monotype Urdu 507
fantasy
Fantasy fonts, as used in CSS, are primarily decorative while still
containing representations of characters (as opposed to Pi or Picture
fonts, which do not represent characters). Examples include:
Latin fonts Alpha Geometrique, Critter, Cottonwood, FB Reactor, Studz
monospace
The sole criterion of a monospace font is that all glyphs have the
same fixed width. (This can make some scripts, such as Arabic, look
most peculiar.) The effect is similar to a manual typewriter, and is
often used to set samples of computer code.
Examples of fonts which fit this description include:
Latin fonts Courier, MS Courier New, Prestige, Everson Mono
Greek Fonts MS Courier New, Everson Mono
Cyrillic fonts ER Kurier, Everson Mono
Japanese fonts Osaka Monospaced
Cherokee fonts Everson Mono
15.3 Font selection
The second phase of the CSS2 font mechanism concerns the user agent's
selection of a font based on author-specified font properties,
available fonts, etc. The details of the font matching algorithm are
provided below.
There are four possible font selection actions: name matching,
intelligent matching, synthesis, and download.
font name matching
In this case, the user agent uses an existing, accessible font
that has the same family name as the requested font. (Note that
the appearance and the metrics might not necessarily match, if
the font that the document author used and the font on the
client system are from different foundries). The matching
information is restricted to the CSS font properties, including
the family name. This is the only method used by CSS1.
intelligent font matching
In this case, the user agent uses an existing, accessible font
that is the closest match in appearance to the requested font.
(Note that the metrics might not match exactly). The matching
information includes information about the kind of font (text
or symbol), nature of serifs, weight, cap height, x height,
ascent, descent, slant, etc.
font synthesis
In this case, the user agent creates a font that is not only a
close match in appearance, but also matches the metrics of the
requested font. The synthesizing information includes the
matching information and typically requires more accurate
values for the parameters than are used for some matching
schemes. In particular, synthesis requires accurate width
metrics and character to glyph substitution and position
information if all the layout characteristics of the specified
font are to be preserved.
font download
Finally, the user agent may retrieve a font over the Web. This
is similar to the process of fetching images, sounds, or
applets over the Web for display in the current document, and
likewise can cause some delay before the page can be displayed.
Progressive rendering is a combination of download and one of the
other methods; it provides a temporary substitute font (using name
matching, intelligent matching, or synthesis) to allow content to be
read while the requested font downloads. Once the real font has been
successfully downloaded, it replaces the temporary font, hopefully
without the need to reflow.
Note. Progressive rendering requires metric information about the font
in order to avoid re-layout of the content when the actual font has
been loaded and rendered. This metric information is sufficiently
verbose that it should only be specified at most once per font in a
document.
15.3.1 Font Descriptions and @font-face
The font description provides the bridge between an author's font
specification and the font data, which is the data needed to format
text and to render the abstract glyphs to which the characters map -
the actual scalable outlines or bitmaps. Fonts are referenced by style
sheet properties.
The font description is added to the font database and then used to
select the relevant font data. The font description contains
descriptors such as the location of the font data on the Web, and
characterizations of that font data. The font descriptors are also
needed to match the style sheet font properties to particular font
data. The level of detail of a font description can vary from just the
name of the font up to a list of glyph widths.
Font descriptors may be classified into three types:
1. those that provide the link between the CSS usage of the font and
the font description (these have the same names as the
corresponding CSS font properties),
2. the URI for the location of the font data,
3. those that further characterize the font, to provide a link
between the font description and the font data.
All font descriptions are specified via a @font-face at-rule. The
general form is:
@font-face { }
where the has the form:
descriptor: value;
descriptor: value;
[...]
descriptor: value;
Each @font-face rule specifies a value for every font descriptor,
either implicitly or explicitly. Those not given explicit values in
the rule take the initial value listed with each descriptor in this
specification. These descriptors apply solely within the context of
the @font-face rule in which they are defined, and do not apply to
document language elements. Thus, there is no notion of which elements
the descriptors apply to, or whether the values are inherited by child
elements.
The available font descriptors are described in later sections of this
specification.
For example, here the font 'Robson Celtic' is defined and referenced
in a style sheet contained in an HTML document.
Font test
This heading is displayed using Robson Celtic
The style sheet (in the STYLE element) contains a CSS rule that sets
all H1 elements to use the 'Robson Celtic' font family.
A CSS1 implementation will search the client for a font whose family
name and other properties match 'Robson Celtic' and, if it fails to
find it, will use the UA-specific fallback serif font (which is
defined to exist).
A user agent implementing CSS2 will first examine @font-face rules in
search of a font description defining 'Robson Celtic'. This example
contains a rule which matches. Although this rule doesn't contain much
font data, it does have a URI where the font can be retrieved for
rendering this document. Downloaded fonts should not be made available
to other applications. If no matching @font-face is found, the user
agent will attempt the same match as a user agent implementing CSS1.
Note that if the font 'Robson Celtic' had been installed on the client
system, this would cause the UA to add an entry in the font database
for the installed copy as described in the section on the font
matching algorithm. The installed copy would have been matched before
the downloadable font in the example above.
CSS1 implementations, which do not understand the @font-face rule,
will encounter the opening curly brackets and will ignore forward
until the matching closing curly brackets. This at-rule conforms with
the forward-compatible parsing requirement of CSS. Parsers may ignore
these rules without error.
Having the font descriptors separate from the font data has a benefit
beyond being able to do font selection and/or substitution. The data
protection and replication restrictions on the font descriptors may be
much weaker than on the full font data. Thus, it may be possible to
locally install the font definition, or at least to have it in a local
cache if it occurs in a commonly-referenced style sheet; which would
not require accessing the full font definition over the Web more than
once per named font.
If a font descriptor is duplicated, the last occurring descriptor wins
and the rest must be ignored.
Also, any descriptors that are not recognized or useful to the user
agent should be ignored. Future versions of CSS may allow additional
descriptors for the purpose of better font substitution, matching, or
synthesis.
15.3.2 Descriptors for Selecting a Font: 'font-family', 'font-style',
'font-variant', 'font-weight', 'font-stretch' and 'font-size'
The following descriptors have the same names as the corresponding
CSS2 font properties, and take a single value or comma-separated list
of values.
The values within that list are, except as explicitly noted, the same
as those for the corresponding CSS2 property. If there is a single
value, that is the value that must be matched. If there is a list, any
list item constitutes a match. If the descriptor is omitted from the
@font-face, the initial value for the descriptor is used.
'font-family' (Descriptor)
Value: [ | ] [, [
| ]]*
Initial: depends on user agent
Media: visual
This is the descriptor for the font family name of a font and takes
the same values as the 'font-family' property.
'font-style' (Descriptor)
Value: all | [ normal | italic | oblique ] [, [normal |
italic | oblique] ]*
Initial: all
Media: visual
This is the descriptor for the style of a font and takes the same
values as the 'font-style' property, except that a comma-separated
list is permitted.
'font-variant' (Descriptor)
Value: [normal | small-caps] [,[normal | small-caps]]*
Initial: normal
Media: visual
This is the CSS indication of whether this face is the small-caps
variant of a font. It takes the same values as the 'font-variant'
property except that a comma-separated list is permitted.
Note. Cyrillic pryamoĭ faces may be labeled with a 'font-variant'
of small-caps, which will give better consistency with Latin faces
(and the companion kursiv face labeled with 'font-style' italic for
the same reason).
'font-weight' (Descriptor)
Value: all | [normal | bold | 100 | 200 | 300 | 400 | 500 |
600 | 700 | 800 | 900] [, [normal | bold | 100 | 200 | 300 |
400 | 500 | 600 | 700 | 800 | 900]]*
Initial: all
Media: visual
This is the descriptor for the weight of a face relative to others in
the same font family. It takes the same values as the 'font-weight'
property with three exceptions:
1. relative keywords (bolder, lighter) are not permitted.
2. a comma-separated list of values is permitted, for fonts which
contain multiple weights.
3. an additional keyword, 'all' is permitted, which means that the
font will match for all possible weights; either because it
contains multiple weights, or because that face only has a single
weight.
'font-stretch' (Descriptor)
Value: all | [ normal | ultra-condensed | extra-condensed |
condensed | semi-condensed | semi-expanded | expanded |
extra-expanded | ultra-expanded ] [, [ normal | ultra-condensed
| extra-condensed | condensed | semi-condensed | semi-expanded
| expanded | extra-expanded | ultra-expanded] ]*
Initial: normal
Media: visual
This is the CSS indication of the condensed or expanded nature of the
face relative to others in the same font family. It takes the same
values as the 'font-stretch' property except that:
* relative keywords (wider, narrower) are not permitted
* a comma-separated list is permitted
* The keyword 'all' is permitted
'font-size' (Descriptor)
Value: all | [ [,[]]* ]
Initial: all
Media: visual
This is the descriptor for the sizes provided by this font. Only
absolute length units are permitted, in contrast to the 'font-size'
property, which allows both relative and absolute lengths and sizes. A
comma-separated list of absolute lengths is permitted.
The initial value of 'all' is suitable for most scalable fonts, so
this descriptor is primarily for use in an @font-face for bitmap
fonts, or scalable fonts designed to be rasterised at a restricted
range of font sizes.
15.3.3 Descriptors for Font Data Qualification: 'unicode-range'
The following descriptor is optional within a font definition, but is
used to avoid checking or downloading a font that does not have
sufficient glyphs to render a particular character.
'unicode-range' (Descriptor)
Value: +
Initial: U+0-7FFFFFFF
Media: visual
This is the descriptor for the range of ISO 10646 characters covered
by the font.
The values of are expressed using hexadecimal numbers
prefixed by "U+", corresponding to character code positions in ISO
10646 ([ISO10646]).
For example, U+05D1 is the ISO 10646 character 'Hebrew letter bet'.
For values outside the Basic Multilingual Plane (BMP), additional
leading digits corresponding to the plane number are added, also in
hexadecimal, like this: U+A1234 which is the character on Plane 10 at
hexadecimal code position 1234. At the time of writing no characters
had been assigned outside the BMP. Leading zeros (for example,
0000004D) are valid, but not required.
The initial value (i.e., the value used when no value is given in the
style sheet) covers not only the entire Basic Multilingual Plane
(BMP), which would be expressed as U+0-FFFF, but also the whole
repertoire of ISO 10646. Thus, the initial value says that the font
may have glyphs for characters anywhere in ISO 10646. Specifying a
value for 'unicode-range' provides information to make searching
efficient, by declaring a constrained range in which the font may have
glyphs for characters. The font need not be searched for characters
outside this range.
Values may be written with any number of digits. For single numbers,
the character '?' is assumed to mean 'any value' which creates a range
of character positions. Thus, using a single number:
unicode-range: U+20A7
no wild cards - it indicates a single character position (the
Spanish peseta currency symbol)
unicode-range: U+215?
one wild card, covers the range 2150 to 215F (the fractions)
unicode-range: U+00??
two wild cards, covers the range 0000 to 00FF (Latin-1)
unicode-range: U+E??
two wild cards, covers 0E00 to 0EFF (the Lao script)
A pair of numbers in this format can be combined with the dash
character to indicate larger ranges. For example:
unicode-range: U+AC00-D7FF
the range is AC00 to D7FF (the Hangul Syllables area)
Multiple, discontinuous ranges can be specified, separated by a comma.
As with other comma-separated lists in CSS, any whitespace before or
after the comma is ignored. For example:
unicode-range: U+370-3FF, U+1F??
This covers the range 0370 to 03FF (Modern Greek) plus 1F00 to
1FFF (Ancient polytonic Greek).
unicode-range: U+3000-303F, U+3100-312F, U+32??, U+33??, U+4E00-9FFF,
U+F9000-FAFF, U+FE30-FE4F
Something of a worst case in terms of verbosity, this very
precisely indicates that this (extremely large) font contains
only Chinese characters from ISO 10646, without including any
characters that are uniquely Japanese or Korean. The range is
3000 to 303F (CJK symbols and punctuation) plus 3100 to 312F
(Bopomofo) plus 3200 to 32FF (enclosed CJK letters and months)
plus 3300 to 33FF (CJK compatibility zone) plus 4E00 to 9FFF
(CJK unified Ideographs) plus F900 to FAFF (CJK compatibility
ideographs) plus FE30 to FE4F (CJK compatibility forms).
A more likely representation for a typical Chinese font would
be:
unicode-range: U+3000-33FF, U+4E00-9FFF
unicode-range: U+11E00-121FF
This font covers a proposed registration for Aztec pictograms,
covering the range 1E00 to 21FF in plane 1.
unicode-range: U+1A00-1A1F
This font covers a proposed registration for Irish Ogham
covering the range 1A00 to 1A1F
15.3.4 Descriptor for Numeric Values: 'units-per-em'
The following descriptor specifies the number of "units" per em; these
units may be used by several other descriptors to express various
lengths, so 'units-per-em' is required if other descriptors depend on
it.
'units-per-em' (Descriptor)
Value:
Initial: undefined
Media: visual
This is the descriptor for the number of the coordinate units on the
em square, the size of the design grid on which glyphs are laid out.
15.3.5 Descriptor for Referencing: 'src'
This descriptor is required for referencing actual font data, whether
downloadable or locally installed.
'src' (Descriptor)
Value: [ [format( [, ]*)] |
] [, [format( [, ]*)] |
]*
Initial: undefined
Media: visual
This is a prioritized, comma-separated list of external references
and/or locally installed font face names. The external reference
points to the font data on the Web. This is required if the WebFont is
to be downloaded. The font resource may be a subset of the source
font, for example it may contain only the glyphs needed for the
current page or for a set of pages.
The external reference consists of a URI, followed by an optional hint
regarding the format of font resource to be found at that URI, and
this information should be used by clients to avoid following links to
fonts in formats they are unable to use. As with any hypertext
reference, there may be other formats available, but the client has a
better idea of what is likely to be there, in a more robust way than
trying to parse filename extensions in URIs.
The format hint contains a comma-separated list of format strings that
denote well-known font formats. The user agent will recognize the name
of font formats that it supports, and will avoid downloading fonts in
formats that it does not recognize.
An initial list of format strings defined by this specification and
representing formats likely to be used by implementations on various
platforms is:
String Font Format Examples of common extensions
"truedoc-pfr" TrueDoc® Portable Font Resource .pfr
"embedded-opentype" Embedded OpenType .eot
"type-1" PostScript® Type 1 .pfb, .pfa
"truetype" TrueType .ttf
"opentype" OpenType, including TrueType Open .ttf
"truetype-gx" TrueType with GX extensions
"speedo" Speedo
"intellifont" Intellifont
As with other URIs in CSS, the URI may be partial, in which case it is
resolved relative to the location of the style sheet containing the
@font-face.
The is the full font name of a locally installed
font. The full font name is the name of the font as reported by the
operating system and is the name most likely to be used in reader
style sheets, browser default style sheets or possibly author style
sheets on an intranet. Adornments such as bold, italic, underline are
often used to differentiate faces within a font family. For more
information about full font names please consult the notes below.
Examples:
src: url(http://foo/bar)
a full URI and no information about the font format(s)
available there
src: local(BT Century 751 No. 2 Semi Bold Italic)
references a particular face of a locally installed font
src: url(../fonts/bar) format("truedoc-pfr")
a partial URI which has a font available in TrueDoc format
src: url(http://cgi-bin/bar?stuff) format("opentype", "intellifont")
a full URI, in this case to a script, which can generate two
different formats - OpenType and Intellifont
src: local(T-26 Typeka Mix), url(http://site/magda-extra)
format("type-1")
two alternatives are given, firstly a locally installed font
and secondly a downloadable font available in Type 1 format.
Access to locally installed fonts is via the . The
font face name is not truly unique, nor is it truly platform or font
format independent, but at the moment it is the best way to identify
locally installed font data. The use of the font face name can be made
more accurate by providing an indication of the glyph complement
required. This may be done by indicating the range of ISO 10646
character positions for which the font provides some glyphs (see
'unicode-range').
15.3.6 Descriptors for Matching: 'panose-1', 'stemv', 'stemh', 'slope',
'cap-height', 'x-height', 'ascent', and 'descent'
These descriptors are optional for a CSS2 definition, but may be used
if intelligent font matching or font size adjustment is desired by the
author.
'panose-1' (Descriptor)
Value: []{10}
Initial: 0 0 0 0 0 0 0 0 0 0
Media: visual
This is the descriptor for the Panose-1 number and consists of ten
decimal numbers, separated by whitespace. A comma-separated list is
not permitted for this descriptor, because the Panose-1 system can
indicate that a range of values are matched. The initial value is
zero, which means "any", for each PANOSE digit; all fonts will match
the Panose number if this value is used. Use of the Panose-1
descriptor is strongly recommended for latin fonts.
'stemv' (Descriptor)
Value:
Initial: undefined
Media: visual
This is the descriptor for the vertical stem width of the font. If the
value is undefined, the descriptor is not used for matching. If this
descriptor is used, the 'units-per-em' descriptor must also be used.
'stemh' (Descriptor)
Value:
Initial: undefined
Media: visual
This is the descriptor for the horizontal stem width of the font. If
the value is undefined, the descriptor is not used for matching. If
this descriptor is used, the 'units-per-em' descriptor must also be
used.
'slope' (Descriptor)
Value:
Initial: 0
Media: visual
This is the descriptor for the vertical stroke angle of the font.
'cap-height' (Descriptor)
Value:
Initial: undefined
Media: visual
This is the descriptor for the number of the height of uppercase
glyphs of the font. If the value is undefined, the descriptor is not
used for matching. If this descriptor is used, the 'units-per-em'
descriptor must also be used.
'x-height' (Descriptor)
Value:
Initial: undefined
Media: visual
This is the descriptor for the height of lowercase glyphs of the font.
If the value is undefined, the descriptor is not used for matching. If
this descriptor is used, the 'units-per-em' descriptor must also be
used. This descriptor can be very useful when using the
'font-size-adjust' property, because computation of the z value of
candidate fonts requires both the font size and the x-height; it is
therefore recommended to include this descriptor.
'ascent' (Descriptor)
Value:
Initial: undefined
Media: visual
This is the descriptor for the maximum unaccented height of the font.
If the value is undefined, the descriptor is not used for matching. If
this descriptor is used, the 'units-per-em' descriptor must also be
used.
'descent' (Descriptor)
Value:
Initial: undefined
Media: visual
This is the descriptor for the Maximum unaccented depth of the font.
If the value is undefined, the descriptor is not used for matching. If
this descriptor is used, the 'units-per-em' descriptor must also be
used.
15.3.7 Descriptors for Synthesis: 'widths', 'bbox' and 'definition-src'
Synthesizing a font means, at minimum, matching the width metrics of
the specified font. Therefore, for synthesis, this metric information
must be available. Similarly, progressive rendering requires width
metrics in order to avoid reflow of the content when the actual font
has been loaded. Although the following descriptors are optional for a
CSS2 definition, some are required if synthesizing (or reflow-free
progressive rendering) is desired by the author. Should the actual
font become available, the substitute should be replaced by the actual
font. Any of these descriptors that are present will be used to
provide a better or faster approximation of the intended font.
Of these descriptors, the most important are the 'widths' descriptor
and 'bbox' which are used to prevent text reflow should the actual
font become available. In addition, the descriptors in the set of
descriptors used for matching can be used to provide a better
synthesis of the actual font appearance.
'widths' (Descriptor)
Value: [ ]? [ ]+ [,[ ]? ]+]
Initial: undefined
Media: visual
This is the descriptor for the glyph widths. The value is a
comma-separated list of values each followed by one or more
glyph widths. If this descriptor is used, the 'units-per-em'
descriptor must also be used.
If the is omitted, a range of U+0-7FFFFFFF is assumed which
covers all characters and their glyphs. If not enough glyph widths are
given, the last in the list is replicated to cover that urange. If too
many widths are provided, the extras are ignored.
For example:
widths: U+4E00-4E1F 1736 1874 1692
widths: U+1A?? 1490, U+215? 1473 1838 1927 1684 1356 1792
1815 1848 1870 1492 1715 1745 1584 1992 1978 1770
In the first example a range of 32 characters is given, from 4E00 to
4E1F. The glyph corresponding to the first character (4E00) has a
width of 1736, the second has a width of 1874 and the third, 1692.
Because not enough widths have been provided, the last width
replicates to cover the rest of the specified range. The second
example sets a single width, 1490, for an entire range of 256 glyphs
and then explicit widths for a range of 16 glyphs.
This descriptor cannot describe multiple glyphs corresponding to a
single character, or ligatures of multiple characters. Thus, this
descriptor can only be used for scripts which do not have contextual
forms or mandatory ligatures. It is nevertheless useful in those
situations. Scripts which require a one-to-many or many-to-many
mapping of characters to glyphs cannot at present use this descriptor
to enable font synthesis although they can still use font downloading
or intelligent matching.
'bbox' (Descriptor)
Value: , , ,
Initial: undefined
Media: visual
This is the descriptor for the maximal bounding box of the font. The
value is a comma-separated list of exactly four numbers specifying, in
order, the lower left x, lower left y, upper right x, and upper right
y of the bounding box for the complete font.
'definition-src' (Descriptor)
Value:
Initial: undefined
Media: visual
The font descriptors may either be within the font definition in the
style sheet, or may be provided within a separate font definition
resource identified by a URI. The latter approach can reduce network
traffic when multiple style sheets reference the same fonts.
15.3.8 Descriptors for Alignment: 'baseline', 'centerline', 'mathline', and
'topline'
These optional descriptors are used to align runs of different scripts
with one another.
'baseline' (Descriptor)
Value:
Initial: 0
Media: visual
This is the descriptor for the lower baseline of a font. If this
descriptor is given a non-default (non-zero) value, the 'units-per-em'
descriptor must also be used.
'centerline' (Descriptor)
Value:
Initial: undefined
Media: visual
This is the descriptor for the central baseline of a font. If the
value is undefined, the UA may employ various heuristics such as the
midpoint of the ascent and descent values. If this descriptor is used,
the 'units-per-em' descriptor must also be used.
'mathline' (Descriptor)
Value:
Initial: undefined
Media: visual
This is the descriptor for the mathematical baseline of a font. If
undefined, the UA may use the center baseline. If this descriptor is
used, the 'units-per-em' descriptor must also be used.
'topline' (Descriptor)
Value:
Initial: undefined
Media: visual
This is the descriptor for the top baseline of a font. If undefined,
the UA may use an approximate value such as the ascent. If this
descriptor is used, the 'units-per-em' descriptor must also be used.
15.3.9 Examples
Given the following list of fonts:
Swiss 721 light light & light italic
Swiss 721 roman, bold, italic, bold italic
Swiss 721 medium medium & medium italic
Swiss 721 heavy heavy & heavy italic
Swiss 721 black black, black italic, & black #2
Swiss 721 Condensed roman, bold, italic, bold italic
Swiss 721 Expanded roman, bold, italic, bold italic
@font-face {
font-family: "Swiss 721";
src: url(swiss721lt.pfr); /* Swiss 721 light */
font-style: normal, italic;
font-weight: 200;
}
@font-face {
font-family: "Swiss 721";
src: url(swiss721.pfr); /* The regular Swiss 721 */
}
@font-face {
font-family: "Swiss 721";
src: url(swiss721md.pfr); /* Swiss 721 medium */
font-style: normal, italic;
font-weight: 500;
}
@font-face {
font-family: "Swiss 721";
src: url(swiss721hvy.pfr); /* Swiss 721 heavy */
font-style: normal, italic;
font-weight: 700;
}
@font-face {
font-family: "Swiss 721";
src: url(swiss721blk.pfr); /* Swiss 721 black */
font-style: normal, italic;
font-weight: 800,900; /* note the interesting problem that
the 900 weight italic doesn't exist */
}
@font-face {
font-family: "Swiss 721";
src: url(swiss721.pfr); /* The condensed Swiss 721 */
font-stretch: condensed;
}
@font-face {
font-family: "Swiss 721";
src: url(swiss721.pfr); /* The expanded Swiss 721 */
font-stretch: expanded;
}
15.4 Font Characteristics
15.4.1 Introducing Font Characteristics
In this section are listed the font characteristics that have been
found useful for client-side font matching, synthesis, and download
for heterogeneous platforms accessing the Web. The data may be useful
for any medium that needs to use fonts on the Web by some other means
than physical embedding of the font data inside the medium.
These characteristics are used to characterize fonts. They are not
specific to CSS, or to style sheets. In CSS, each characteristic is
described by a font descriptor. These characteristics could also be
mapped onto VRML nodes, or CGM Application Structures, or a Java API,
or alternative style sheet languages. Fonts retrieved by one medium
and stored in a proxy cache could be re-used by another medium, saving
download time and network bandwidth, if a common system of font
characteristics are used throughout.
A non-exhaustive list of examples of such media includes:
* 2-D vector formats
+ Computer Graphics Metafile
+ Simple Vector Format
* 3-D graphics formats
+ VRML
+ 3DMF
* Object embedding technologies
+ Java
+ Active-X
+ Obliq
15.4.2 Full font name
This is the full name of a particular face of a font family. It
typically includes a variety of non-standardized textual qualifiers or
adornments appended to the font family name. It may also include a
foundry name or abbreviation, often prepended to the font family name.
It is only used to refer to locally installed fonts, because the
format of the adorned name can vary from platform to platform.
For example, the font family name of the TrueType font and the
PostScript name may differ in the use of space characters,
punctuation, and in the abbreviation of some words (e.g., to meet
various system or printer interpreter constraints on length of names).
For example, spaces are not allow in a PostScript name, but are common
in full font names. The TrueType name table can also contain the
PostScript name, which has no spaces.
The name of the font definition is important because it is the link to
any locally installed fonts. It is important that the name be robust,
both with respect to platform and application independence. For this
reason, the name should be one which is not application or language
specific.
The ideal solution would be to have a name which uniquely identifies
each collection of font data. This name does not exist in current
practice for font data. Fonts with the same face name can vary over a
number of descriptors. Some of these descriptors, such as different
complements of glyphs in the font, may be insignificant if the needed
glyphs are in the font. Other descriptors, such as different width
metrics, make fonts with the same name incompatible. It does not seem
possible to define a rule that will always identify incompatibilities,
but will not prevent the use of a perfectly suitable local copy of the
font data with a given name. Therefore, only the range of ISO 10646
characters will be used to qualify matches for the font face name.
Since a prime goal of the font face name in the font definition is to
allow a user agent to determine when there is a local copy of the
specified font data, the font face name must be a name which will be
in all legitimate copies of the font data. Otherwise, unnecessary Web
traffic may be generated due to missed matches for the local copy.
15.4.3 Coordinate units on the em square
Certain values, such as width metrics, are expressed in units that are
relative to an abstract square whose height is the intended distance
between lines of type in the same type size. This square is called the
em square and it is the design grid on which the glyph outlines are
defined. The value of this descriptor specifies how many units the EM
square is divided into. Common values are for example 250
(Intellifont), 1000 (Type 1) and 2048 (TrueType, TrueType GX and
OpenType).
If this value is not specified, it becomes impossible to know what any
font metrics mean. For example, one font has lowercase glyphs of
height 450; another has smaller ones of height 890! The numbers are
actually fractions; the first font has 450/1000 and the second has
890/2048 which is indeed smaller.
15.4.4 Central Baseline
This gives the position in the em square of the central baseline. The
central baseline is used by ideographic scripts for alignment, just as
the bottom baseline is used for Latin, Greek and Cyrillic scripts.
15.4.5 Font Encoding
Either explicitly or implicitly, each font has a table associated with
it, the font encoding table, that tells what character each glyph
represents. This table is also referred to as an encoding vector.
In fact, many fonts contain several glyphs for the same character.
Which of those glyphs should be used depends either on the rules of
the language, or on the preference of the designer.
In Arabic, for example, all letters have four (or two) different
shapes, depending on whether the letter is used at the start of a
word, in the middle, at the end, or in isolation. It is the same
character in all cases, and thus there is only one character in the
HTML document, but when printed, it looks different each time.
There are also fonts that leave it to the graphic designer to choose
from among various alternative shapes provided. Unfortunately, CSS2
doesn't yet provide the means to select those alternatives. Currently,
it is always the default shape that is chosen from such fonts.
15.4.6 Font family name
This specifies the family name portion of the font face name. For
example, the family name for Helvetica-Bold is Helvetica and the
family name of ITC Stone Serif Semibold Italic is ITC Stone Serif.
Some systems treat adornments relating to condensed or expanded faces
as if they were part of the family name.
15.4.7 Glyph widths
This is a list of widths, on the design grid, for the glyph
corresponding to each character. The list is ordered by ISO10646 code
point. Widths cannot usefully be specified when more than one glyph
maps to the same character or when there are mandatory ligatures.
15.4.8 Horizontal stem width
This value refers to the dominant stem of the font. There may be two
or more designed widths. For example, the main vertical stems of Roman
characters will differ from the thin stems on serifed "M" and "N",
plus there may be different widths for uppercase and lowercase
characters in the same font. Also, either by design or by error, all
stems may have slightly different widths.
15.4.9 Height of uppercase glyphs
This measurement is the y-coordinate of the top of flat uppercase
letters in Latin, Greek and Cyrillic scripts, measured from the
baseline. This descriptor is not necessarily useful for fonts that do
not contain any glyphs from these scripts.
15.4.10 Height of lowercase glyphs
This measurement is the y-coordinate of the top of unaccented,
non-ascending lowercase letters in Latin, Greek and Cyrillic scripts,
measured from the baseline. Flat-topped letters are used, ignoring any
optical correction zone. This is usually used as a ratio of lowercase
to uppercase heights, as a means of comparison between font families.
Illustration of x-height
This descriptor is not useful for fonts that do not contain any glyphs
from these scripts. Since the heights of lowercase and uppercase
letters are often formed into a ratio for comparing different fonts,
it may be useful to set both the lowercase and uppercase heights to
the same value for unicameral scripts such as Hebrew, where for mixed
Latin and Hebrew text the Hebrew characters are typically set at a
height midway between the uppercase and lowercase heights of the Latin
font.
Height of Hebrew characters
15.4.11 Lower Baseline
This gives the position in the em square of the lower baseline. The
lower baseline is used by Latin, Greek and Cyrillic scripts for
alignment, just as the upper baseline is used for Sanscrit-derived
scripts.
15.4.12 Mathematical Baseline
This gives the position in the em square of the mathematical baseline.
The mathematical baseline is used by mathematical symbols for
alignment, just as the lower baseline is used for Latin, Greek, and
Cyrillic scripts.
15.4.13 Maximal bounding box
The maximal bounding box is the smallest rectangle enclosing the shape
that results if all glyphs in the font are placed with their origins
coincident, and then painted.
If a dynamically downloadable font has been generated by subsetting a
parent font, the bbox should be that of the parent font.
15.4.14 Maximum unaccented height
This measurement, on the em square, is from the baseline to the
highest point reached by any glyph, excluding any accents or
diacritical marks.
Diagram showing several glyphs and the maximum unaccented height
15.4.15 Maximum unaccented depth
This measurement, on the em square, is from the baseline to the lowest
point reached by any glyph, excluding any accents or diacritical
marks.
Diagram showing several glyphs and the maximum unaccented depth
15.4.16 Panose-1 number
Panose-1 is an industry standard TrueType font classification and
matching technology. The PANOSE system consists of a set of ten
numbers that categorize the key attributes of a Latin typeface, a
classification procedure for creating those numbers, and Mapper
software that determines the closest possible font match given a set
of typefaces. The system could, with modification, also be used for
Greek and Cyrillic, but is not suitable for unicameral and ideographic
scripts (Hebrew, Armenian, Arabic, Chinese/Japanese/Korean).
15.4.17 Range of ISO 10646 characters
This indicates the glyph repertoire of the font, relative to ISO 10646
(Unicode). Since this is sparse (most fonts do not cover the whole of
ISO 10646) this descriptor lists blocks or ranges which do have some
coverage (no promise is made of complete coverage) and is used to
eliminate unsuitable fonts (ones that will not have the required
glyphs). It does not indicate that the font definitely has the
required glyphs, only that it is worth downloading and looking at the
font. See [ISO10646] for information about useful documents.
This method is extensible to future allocation of characters in
Unicode, without change of syntax and without invalidating existing
content.
Font formats that do not include this information, explicitly or
indirectly, may still use this characteristic, but the value must be
supplied by the document or style sheet author.
There are other classifications into scripts, such as the Monotype
system (see [MONOTYPE]) and a proposed ISO script system. These are
not readily extensible.
Because of this, classification of glyph repertoires by the range of
ISO 10646 characters that may be represented with a particular font is
used in this specification. This system is extensible to cover any
future allocation.
15.4.18 Top Baseline
This gives the position in the em square of the top baseline. The top
baseline is used by Sanscrit-derived scripts for alignment, just as
the bottom baseline is used for Latin, Greek and Cyrillic scripts.
15.4.19 Vertical stem width
This is the width of vertical (or near-vertical) stems of glyphs. This
information is often tied to hinting, and may not be directly
accessible in some font formats. The measurement should be for the
dominant vertical stem in the font because there might be different
groupings of vertical stems (e.g., one main one, and one lighter
weight one as for an uppercase M or N).
15.4.20 Vertical stroke angle
This is the angle, in degrees counterclockwise from the vertical, of
the dominant vertical strokes of the font. The value is negative for
fonts that slope to the right, as almost all italic fonts do. This
descriptor may also be specified for oblique fonts, slanted fonts,
script fonts, and in general for any font whose vertical strokes are
not precisely vertical. A non-zero value does not of itself indicate
an italic font.
15.5 Font matching algorithm
This specification extends the algorithm given in the CSS1
specification. This algorithm reduces down to the algorithm in the
CSS1 specification when the author and reader style sheets do not
contain any @font-face rules.
Matching of descriptors to font faces must be done carefully. The
descriptors are matched in a well-defined order to insure that the
results of this matching process are as consistent as possible across
UAs (assuming that the same library of font faces and font
descriptions is presented to each of them). This algorithm may be
optimized, provided that an implementation behaves as if the algorithm
had been followed exactly.
1. The user agent makes (or accesses) a database of relevant
font-face descriptors of all the fonts of which the UA is aware.
If there are two fonts with exactly the same descriptors, one of
them is ignored. The UA may be aware of a font because:
+ it has been installed locally
+ it is declared using an @font-face rule in one of the style
sheets linked to or contained in the current document
+ it is used in the UA default style sheet, which conceptually
exists in all UAs and is considered to have full @font-face
rules for all fonts which the UA will use for default
presentation, plus @font-face rules for the five special
generic font families (see 'font-family') defined in CSS2
2. At a given element and for each character in that element, the UA
assembles the font properties applicable to that element. Using
the complete set of properties, the UA uses the 'font-family'
descriptor to choose a tentative font family. Thus, matching on a
family name will succeed before matching on some other descriptor.
The remaining properties are tested against the family according
to the matching criteria described with each descriptor. If there
are matches for all the remaining properties, then that is the
matching font face for the given element.
3. If there is no matching font face within the 'font-family' being
processed by step 2, UAs which implement intelligent matching may
proceed to examine other descriptors such as x-height, glyph
widths, and panose-1 to identify a different tentative font
family. If there are matches for all the remaining descriptors,
then that is the matching font face for the given element. The
font-family descriptor that is reflected into the CSS2 properties
is the font family that was requested, not whatever name the
intelligently matched font may have. UAs that do not implement
intelligent matching are considered to fail at this step.
4. If there is no matching font face within the 'font-family' being
processed by step 3, UAs that implement font downloading may
proceed to examine the src descriptor of the tentative font face
identified in step 2 or 3 to identify a network resource that is
available, and of the correct format. If there are matches for all
the remaining descriptors, then that is the matching font face for
the given element and the UA may attempt to download this font
resource. The UA may choose to block on this download or may
choose to proceed to the next step while the font downloads. UAs
that do not implement font download, or are not connected to a
network, or where the user preferences have disabled font
download, or where the requested resource is unavailable for
whatever reason, or where the downloaded font cannot be used for
whatever reason, are considered to fail at this step.
5. If there is no matching font face within the 'font-family' being
processed by step 3, UAs that implement font synthesis may proceed
to examine other descriptors such as x-height, glyph widths, and
panose-1 to identify a different tentative font family for
synthesis. If there are matches for all the remaining descriptors,
then that is the matching font face for the given element and
synthesis of the faux font may begin. UAs that do not implement
font synthesis are considered to fail at this step.
6. If all of steps 3, 4 and 5 fail, and if there is a next
alternative 'font-family' in the font set, then repeat from step 2
with the next alternative 'font-family'.
7. If there is a matching font face, but it doesn't contain glyph(s)
for the current character(s), and if there is a next alternative
'font-family' in the font sets, then repeat from step 2 with the
next alternative 'font-family'. The 'unicode-range' descriptor may
be used to rapidly eliminate from consideration those font faces
that do not have the correct glyphs. If the 'unicode-range'
descriptor indicates that a font contains some glyphs in the
correct range, it may be examined by the UA to see if it has that
particular one.
8. If there is no font within the family selected in 2, then use the
inherited or UA-dependent 'font-family' value and repeat from step
2, using the best match that can be obtained within this font. If
a particular character cannot be displayed using this font, the UA
should indicate that a character is not being displayed (for
example, using the 'missing character' glyph).
9. UAs that implement progressive rendering and have pending font
downloads may, once download is successful, use the downloaded
font as a font family. If the downloaded font is missing some
glyphs that the temporary progressive font did contain, the
downloaded font is not used for that character and the temporary
font continues to be used.
Note. The above algorithm can be optimized to avoid having to revisit
the CSS2 properties for each character.
The per-descriptor matching rules from (2) above are as follows:
1. 'font-style' is tried first. 'italic' will be satisfied if there
is either a face in the UA's font database labeled with the CSS
keyword 'italic' (preferred) or 'oblique'. Otherwise the values
must be matched exactly or font-style will fail.
2. 'font-variant' is tried next. 'normal' matches a font not labeled
as 'small-caps'; 'small-caps' matches (1) a font labeled as
'small-caps', (2) a font in which the small caps are synthesized,
or (3) a font where all lowercase letters are replaced by
uppercase letters. A small-caps font may be synthesized by
electronically scaling uppercase letters from a normal font.
3. 'font-weight' is matched next, it will never fail. (See
'font-weight' below.)
4. 'font-size' must be matched within a UA-dependent margin of
tolerance. (Typically, sizes for scalable fonts are rounded to the
nearest whole pixel, while the tolerance for bitmapped fonts could
be as large as 20%.) Further computations, e.g. by 'em' values in
other properties, are based on the 'font-size' value that is used,
not the one that is specified.
15.5.1 Mapping font weight values to font names
The 'font-weight' property values are given on a numerical scale in
which the value '400' (or 'normal') corresponds to the "normal" text
face for that family. The weight name associated with that face will
typically be Book, Regular, Roman, Normal or sometimes Medium.
The association of other weights within a family to the numerical
weight values is intended only to preserve the ordering of weights
within that family. User agents must map names to values in a way that
preserves visual order; a face mapped to a value must not be lighter
than faces mapped to lower values. There is no guarantee on how a user
agent will map font faces within a family to weight values. However,
the following heuristics tell how the assignment is done in typical
cases:
* If the font family already uses a numerical scale with nine values
(as e.g. OpenType does), the font weights should be mapped
directly.
* If there is both a face labeled Medium and one labeled Book,
Regular, Roman or Normal, then the Medium is normally assigned to
the '500'.
* The font labeled "Bold" will often correspond to the weight value
'700'.
* If there are fewer then 9 weights in the family, the default
algorithm for filling the "holes" is as follows. If '500' is
unassigned, it will be assigned the same font as '400'. If any of
the values '600', '700', '800', or '900' remains unassigned, they
are assigned to the same face as the next darker assigned keyword,
if any, or the next lighter one otherwise. If any of '300', '200',
or '100' remains unassigned, it is assigned to the next lighter
assigned keyword, if any, or the next darker otherwise.
There is no guarantee that there will be a darker face for each of the
'font-weight' values; for example, some fonts may have only a normal
and a bold face, others may have eight different face weights.
The following two examples show typical mappings.
Assume four weights in the "Rattlesnake" family, from lightest to
darkest: Regular, Medium, Bold, Heavy.
CAPTION: First example of font-weight mapping
Available faces Assignments Filling the holes
"Rattlesnake Regular" 400 100, 200, 300
"Rattlesnake Medium" 500
"Rattlesnake Bold" 700 600
"Rattlesnake Heavy" 800 900
Assume six weights in the "Ice Prawn" family: Book, Medium, Bold,
Heavy, Black, ExtraBlack. Note that in this instance the user agent
has decided not to assign a numeric value to "Example2 ExtraBlack".
CAPTION: Second example of font-weight mapping
Available faces Assignments Filling the holes
"Ice Prawn Book" 400 100, 200, 300
"Ice Prawn Medium" 500
"Ice Prawn Bold" 700 600
"Ice Prawn Heavy" 800
"Ice Prawn Black" 900
"Ice Prawn ExtraBlack" (none)
15.5.2 Examples of font matching
The following example defines a specific font face, Alabama Italic. A
panose font description and source URI for retrieving a truetype
server font are also provided. Font-weight and font-style descriptors
are provided to describe the font. The declaration says that the
weight will also match any request in the range 300 to 500. The font
family is Alabama and the adorned font name is Alabama Italic.
@font-face {
src: local(Alabama Italic),
url(http://www.fonts.org/A/alabama-italic) format(truetype);
panose-1: 2 4 5 2 5 4 5 9 3 3;
font-family: Alabama, serif;
font-weight: 300, 400, 500;
font-style: italic, oblique;
}
The next example defines a family of fonts. A single URI is provided
for retrieving the font data. This data file will contain multiple
styles and weights of the named font. Once one of these @font-face
definitions has been dereferenced, the data will be in the UA cache
for other faces that use the same URI.
@font-face {
src: local(Helvetica Medium),
url(http://www.fonts.org/sans/Helvetica_family) format(truedoc);
font-family: "Helvetica";
font-style: normal
}
@font-face {
src: local(Helvetica Oblique),
url(http://www.fonts.org/sans/Helvetica_family) format(truedoc);
font-family: "Helvetica";
font-style: oblique;
slope: -18
}
The following example groups three physical fonts into one virtual
font with extended coverage. In each case, the adorned font name is
given in the src descriptor to allow locally installed versions to be
preferentially used if available. A fourth rule points to a font with
the same coverage, but contained in a single resource.
@font-face {
font-family: Excelsior;
src: local(Excelsior Roman), url(http://site/er) format(intellifont);
unicode-range: U+??; /* Latin-1 */
}
@font-face {
font-family: Excelsior;
src: local(Excelsior EastA Roman), url(http://site/ear) format(intellifont);
unicode-range: U+100-220; /* Latin Extended A and B */
}
@font-face {
font-family: Excelsior;
src: local(Excelsior Cyrillic Upright), url(http://site/ecr) format(intellifo
nt);
unicode-range: U+4??; /* Cyrillic */
}
@font-face {
font-family: Excelsior;
src: url(http://site/excels) format(truedoc);
unicode-range: U+??,U+100-220,U+4??;
}
This next example might be found in a UA's default style sheet. It
implements the CSS2 generic font family, serif by mapping it to a wide
variety of serif fonts that might exist on various platforms. No
metrics are given since these vary between the possible alternatives.
@font-face {
src: local(Palatino),
local(Times New Roman),
local(New York),
local(Utopia),
url(http://somewhere/free/font);
font-family: serif;
font-weight: 100, 200, 300, 400, 500;
font-style: normal;
font-variant: normal;
font-size: all
}
_________________________________________________________________
_________________________________________________________________
16 Text
Contents
* 16.1 Indentation: the 'text-indent' property
* 16.2 Alignment: the 'text-align' property
* 16.3 Decoration
+ 16.3.1 Underlining, overlining, striking, and blinking: the
'text-decoration' property
+ 16.3.2 Text shadows: the 'text-shadow' property
* 16.4 Letter and word spacing: the 'letter-spacing' and
'word-spacing' properties
* 16.5 Case
+ 16.5.1 Capitalization: the 'text-transform' property
+ 16.5.2 Special first letter/first line
* 16.6 White space: the 'white-space' property
+ 16.6.1 Line breaks
The properties defined in the following sections affect the visual
presentation of characters, spaces, words, and paragraphs.
16.1 Indentation: the 'text-indent' property
'text-indent'
Value: | | inherit
Initial: 0
Applies to: block-level elements
Inherited: yes
Percentages: refer to width of containing block
Media: visual
This property specifies the indentation of the first line of text in a
block. More precisely, it specifies the indentation of the first box
that flows into the block's first line box. The box is indented with
respect to the left (or right, for right-to-left layout) edge of the
line box. User agents should render this indentation as blank space.
Values have the following meanings:
The indentation is a fixed length.
The indentation is a percentage of the containing block width.
The value of 'text-indent' may be negative, but there may be
implementation-specific limits.
The following example causes a 3em text indent.
P { text-indent: 3em }
16.2 Alignment: the 'text-align' property
'text-align'
Value: left | right | center | justify | | inherit
Initial: depends on user agent and writing direction
Applies to: block-level elements
Inherited: yes
Percentages: N/A
Media: visual
This property describes how a block of text is aligned. Values have
the following meanings:
left, right, center, and justify
Left, right, center, and double justify text, respectively.
Specifies a string on which cells in a table column will align
(see the section on horizontal alignment in a column for
details and an example). This value applies only to table
columns.
A block of text is a stack of line boxes. In all cases except for
'justify', this property specifies how the inline boxes within each
line box align with respect to the line box's left and right sides;
alignment is not with respect to the viewport. In the case of
'justify', the UA may stretch the inline boxes in addition to
adjusting their positions.
In this example, note that since 'text-align' is inherited, all
block-level elements inside the DIV element with 'class=center' will
be centered.
DIV.center { text-align: center }
Note. The actual justification algorithm used is user-agent and
written language dependent.
Conforming HTML user agents may interpret the value 'justify' as
'left' or 'right', depending on whether the element's default writing
direction is left-to-right or right-to-left, respectively.
16.3 Decoration
16.3.1 Underlining, overlining, striking, and blinking: the 'text-decoration'
property
'text-decoration'
Value: none | [ underline || overline || line-through ||
blink ] | inherit
Initial: none
Applies to: all elements
Inherited: no (see prose)
Percentages: N/A
Media: visual
This property describes decorations that are added to the text of an
element. If the property is specified for a block-level element, it
affects all inline-level descendants of the element. If it is
specified for (or affects) an inline-level element, it affects all
boxes generated by the element. If the element has no content or no
text content (e.g., the IMG element in HTML), user agents must ignore
this property.
Values have the following meanings:
none
Produces no text decoration.
underline
Each line of text is underlined.
overline
Each line of text has a line above it.
line-through
Each line of text has a line through the middle
blink
Text blinks (alternates between visible and invisible).
Conforming user agents are not required to support this value.
The color(s) required for the text decoration should be derived from
the 'color' property value.
This property is not inherited, but descendant boxes of a block box
should be rendered with the same decoration (e.g., they should all be
underlined). The color of decorations should remain the same even if
descendant elements have different 'color' values.
In the following example for HTML, the text content of all A elements
acting as hyperlinks will be underlined:
A[href] { text-decoration: underline }
16.3.2 Text shadows: the 'text-shadow' property
'text-shadow'
Value: none | [ || ? ,]*
[ || ?] | inherit
Initial: none
Applies to: all
Inherited: no (see prose)
Percentages: N/A
Media: visual
This property accepts a comma-separated list of shadow effects to be
applied to the text of the element. The shadow effects are applied in
the order specified and may thus overlay each other, but they will
never overlay the text itself. Shadow effects do not alter the size of
a box, but may extend beyond its boundaries. The stack level of the
shadow effects is the same as for the element itself.
Each shadow effect must specify a shadow offset and may optionally
specify a blur radius and a shadow color.
A shadow offset is specified with two values that indicate
the distance from the text. The first length value specifies the
horizontal distance to the right of the text. A negative horizontal
length value places the shadow to the left of the text. The second
length value specifies the vertical distance below the text. A
negative vertical length value places the shadow above the text.
A blur radius may optionally be specified after the shadow offset. The
blur radius is a length value that indicates the boundaries of the
blur effect. The exact algorithm for computing the blur effect is not
specified.
A color value may optionally be specified before or after the length
values of the shadow effect. The color value will be used as the basis
for the shadow effect. If no color is specified, the value of the
'color' property will be used instead.
Text shadows may be used with the :first-letter and :first-line
pseudo-elements.
The example below will set a text shadow to the right and below the
element's text. Since no color has been specified, the shadow will
have the same color as the element itself, and since no blur radius is
specified, the text shadow will not be blurred:
H1 { text-shadow: 0.2em 0.2em }
The next example will place a shadow to the right and below the
element's text. The shadow will have a 5px blur radius and will be
red.
H2 { text-shadow: 3px 3px 5px red }
The next example specifies a list of shadow effects. The first shadow
will be to the right and below the element's text and will be red with
no blurring. The second shadow will overlay the first shadow effect,
and it will be yellow, blurred, and placed to the left and below the
text. The third shadow effect will be placed to the right and above
the text. Since no shadow color is specified for the third shadow
effect, the value of the element's 'color' property will be used:
H2 { text-shadow: 3px 3px red, yellow -3px 3px 2px, 3px -3px }
Consider this example:
SPAN.glow {
background: white;
color: white;
text-shadow: black 0px 0px 5px;
}
Here, the 'background' and 'color' properties have the same value and
the 'text-shadow' property is used to create a "solar eclipse" effect:
Solar eclipse effect
Note. This property is not defined in CSS1. Some shadow effects may
render text invisible in UAs that only support CSS1.
16.4 Letter and word spacing: the 'letter-spacing' and 'word-spacing'
properties
'letter-spacing'
Value: normal | | inherit
Initial: normal
Applies to: all elements
Inherited: yes
Percentages: N/A
Media: visual
This property specifies spacing behavior between text characters.
Values have the following meanings:
normal
This value allows the user agent to alter the space between
characters in order to justify text.
This value indicates inter-character space in addition to the
default space between characters. Values may be negative, but
there may be implementation-specific limits.
Character spacing algorithms are user agent-dependent. Character
spacing may also be influenced by justification (see the 'text-align'
property).
In this example, the space between characters in BLOCKQUOTE elements
is increased by '0.1em'.
BLOCKQUOTE { letter-spacing: 0.1em }
In the following example, the user agent is not permitted to alter
inter-character space, nor to add space:
BLOCKQUOTE { letter-spacing: 0cm } /* Same as '0' */
When the resultant space between two characters is not the same as the
default space, user agents should not use ligatures.
Conforming HTML user agents may consider the value of the
'letter-spacing' property to be 'normal'.
'word-spacing'
Value: normal | | inherit
Initial: normal
Applies to: all elements
Inherited: yes
Percentages: N/A
Media: visual
This property specifies spacing behavior between words. Values have
the following meanings:
normal
This value allows the user agent to alter the space between
words in order to justify text.
This value indicates inter-word space in addition to the
default space between words. Values may be negative, but there
may be implementation-specific limits.
Word spacing algorithms are user agent-dependent. Word spacing may
also be influenced by justification (see the 'text-align' property).
In this example, the word-spacing between each word in H1 elements is
increased by '1em'.
H1 { word-spacing: 1em }
Conforming HTML user agents may consider the value of the
'word-spacing' property to be 'normal'.
16.5 Case
16.5.1 Capitalization: the 'text-transform' property
'text-transform'
Value: capitalize | uppercase | lowercase | none | inherit
Initial: none
Applies to: all elements
Inherited: yes
Percentages: N/A
Media: visual
This property controls capitalization effects of an element's text.
Values have the following meanings:
capitalize
Puts the first character of each word in uppercase.
uppercase
Puts all characters of each word in uppercase.
lowercase
Puts all characters of each word in lowercase.
none
No capitalization effects.
The actual transformation in each case is written language dependent.
See RFC 2070 ([RFC2070]) for ways to find the language of an element.
Conforming HTML user agents may consider the value of 'text-transform'
to be 'none' for characters that are not from the Latin-1 repertoire
and for elements in languages for which the transformation is
different from that specified by the case-conversion tables of ISO
10646 ([ISO10646]).
In this example, all text in an H1 element is transformed to uppercase
text.
H1 { text-transform: uppercase }
16.5.2 Special first letter/first line
Please consult the sections on first line and first letter for
information on specially formatting the first letter or line of a
paragraph.
16.6 White space: the 'white-space' property
'white-space'
Value: normal | pre | nowrap | inherit
Initial: normal
Applies to: block-level elements
Inherited: yes
Percentages: N/A
Media: visual
This property declares how whitespace inside the element is handled.
Values have the following meanings:
normal
This value allows user agents to collapse sequences of white
space. Line breaks may be created by characters or elements
(e.g., the BR element in HTML).
pre
This value prevents user agents from collapsing sequences of
white space.
nowrap
This value suppresses line breaks within text except for those
created by other elements (e.g., the BR element in HTML).
The following examples show what whitespace behavior is expected from
the PRE and P elements in HTML.
PRE { white-space: pre }
P { white-space: normal }
Conforming HTML user agents may ignore the 'white-space' property in
author and user style sheets but must specify a value for it in the
default style sheet.
16.6.1 Line breaks
To force a line break with CSS2, authors may specify one with the
':before' or ':after' pseudo-elements. Thus, the BR element in HTML
may be described as follows:
BR:before { content: "\A"}
See "Generated content and automatic numbering" for explanations of
the 'content' property and the use of the "\A" escape sequence.
_________________________________________________________________
_________________________________________________________________
17 Lists
Contents
* 17.1 Visual formatting of lists
+ 17.1.1 List properties: 'list-style-type',
'list-style-image', 'list-style-position', and 'list-style'
17.1 Visual formatting of lists
CSS allows authors to control the visual presentation of lists in a
number of ways:
* Authors may specify a marker that appears before each list item.
* Markers may be placed outside or inside the list item's content.
* Markers may be represented by predefined shapes (bullets, circles,
squares), numerals (arabic, roman, letters, etc.), or images.
* With descendant selectors and child selectors, it's possible to
specify different marker types depending on the depth of embedded
lists.
An element with a 'display' property value of 'list-item' generates
two boxes: a block box that contains its content and an inline box
that contains a marker. Only the content box is involved with
positioning (e.g, in the normal flow). The position of the marker box
(see the 'list-style-position' property) does not affect the position
of the content box. CSS properties allow authors to specify the marker
type (image, glyph, or number) and its position with respect to the
content box (outside the content or at the beginning of content). CSS
properties do not allow authors to specify distinct style (colors,
fonts, alignment, etc.) for the list marker.
The background properties apply to the content box only; the marker
box is transparent.
The declaration in the following HTML program causes LI elements to
generate 'list-item' boxes. The 'list-style' value 'none' suppresses
preceding markers.
This is the first list item, formatted as a block.
This is the second list item.
This is the third.
The list might be formatted as follows:
A list with no markers.
The illustration shows the relationship between the current left
margin and the margins and padding of the list (UL) box and the list
item (LI) boxes. (The lines delimiting the margins and padding are not
rendered).
If we change the 'list-style' to "square":
LI { display: list-item; list-style: square }
each list item will be preceded by a small square. However, the
placement of the square does not affect the block formatting of the
list item box:
A list with square markers.
The list properties in this chapter do not allow authors to control
the separation between a list marker and the content of its list item.
Instead, this may be achieved with markers. Note that markers
specified with 'display: marker' replace list markers specified with
the list properties defined in this chapter.
Note. There is no "list" presentation for other types of list
structures (e.g., "definition lists" declared by DL, DT, and DD in
HTML). Each part of a definition list is simply a block element.
17.1.1 List properties: 'list-style-type', 'list-style-image',
'list-style-position', and 'list-style'
'list-style-type'
Value: disc | circle | square | decimal | leading-zero |
western-decimal | lower-roman | upper-roman | lower-greek |
lower-alpha | lower-latin | upper-alpha | upper-latin | hebrew
| armenian | georgian | cjk-ideographic | hiragana | katakana |
hiragana-iroha | katakana-iroha | none | inherit
Initial: disc
Applies to: elements with the 'display' property set to
'list-item'
Inherited: yes
Percentages: N/A
Media: visual
This property specifies appearance of the list item marker if
'list-style-image' has the value 'none' or if the image pointed to by
the URI cannot be displayed. The value 'none' specifies no marker,
otherwise there are three types of marker: glyphs, numbering systems,
and alphabetic systems.
Glyphs are specified with disc, circle, and square. Their exact
rendering depends on the user agent.
Numbering systems are specified with:
western-decimal or decimal
Decimal numbers, beginning with 1.
leading-zero
Decimal numbers 01, 02, 03, ... (or 001, 002, 003, ... if more
than 99 items)
lower-roman
Lower case roman numerals (i, ii, iii, iv, v, etc.).
upper-roman
Upper case roman numerals (I, II, III, IV, V, etc.).
hebrew
Traditional Hebrew numbering.
georgian
Traditional Georgian numbering (an, ban, gan, ..., he, tan, in,
in-an, ...).
armenian
Traditional Armenian numbering.
cjk-ideographic
Plain ideographic numbers
hiragana
a, i, u, e, o, ka, ki, ...
katakana
A, I, U, E, O, KA, KI, ...
hiragana-iroha
i, ro, ha, ni, ho, he, to, ...
katakana-iroha
I, RO, HA, NI, HO, HE, TO, ...
A user agent that does not recognize a numbering system should use
'western-decimal'.
Note. This document does not specify the exact mechanism of each
numbering system (e.g., how roman numerals are calculated). A future
W3C Note may provide further clarifications.
Alphabetic systems are specified with:
lower-latin or lower-alpha
Lower case ascii letters (a, b, c, ... z).
upper-latin or upper-alpha
Upper case ascii letters (A, B, C, ... Z).
lower-greek
Lower case classical Greek alpha, beta, gamma, ... (έ,
ή, ί, ...)
This specification does not define how alphabetic systems wrap at the
end of the alphabet. For instance, after 26 list items, 'lower-latin'
rendering is undefined. Therefore, for long lists, we recommend that
authors specify true numbers.
For example, the following HTML document:
This is the first item.
This is the second item.
This is the third item.
might produce something like this:
i This is the first item.
ii This is the second item.
iii This is the third item.
Note that the list marker alignment (here, right justified) depends on
the user agent.
Note. Future versions of CSS may provide more complete mechanisms for
international numbering styles.
'list-style-image'
Value: | none | inherit
Initial: none
Applies to: elements with the 'display' property set to
'list-item'
Inherited: yes
Percentages: N/A
Media: visual
This property sets the image that will be used as the list item
marker. When the image is available, it will replace the marker set
with the 'list-style-type' marker.
The following example sets the marker at the beginning of each list
item to be the image "ellipse.png".
UL { list-style-image: url(http://png.com/ellipse.png) }
'list-style-position'
Value: inside | outside | inherit
Initial: outside
Applies to: elements with the 'display' property set to
'list-item'
Inherited: yes
Percentages: N/A
Media: visual
This property specifies the position of the marker box with respect to
line item content box. Values have the following meanings:
outside
The list item marker is outside the box that is generated for
the list item.
inside
The list item marker is the first inline box generated for the
list item. The list item's contents flow after the marker box.
For example:
first list item comes first
second list item comes second
first list item comes first
second list item comes second
The above example may be formatted as:
Difference between inside and outside list style position
In right-to-left text, the markers would have been on the right side
of the box.
'list-style'
Value: [ <'list-style-type'> || <'list-style-position'> ||
<'list-style-image'> ] | inherit
Initial: not defined for shorthand properties
Applies to: elements with the 'display' property set to
'list-item'
Inherited: yes
Percentages: N/A
Media: visual
The 'list-style' property is a shorthand notation for setting the
three properties 'list-style-type', 'list-style-image', and
'list-style-position' at the same place in the style sheet.
UL { list-style: upper-roman inside } /* Any UL*/
UL > UL { list-style: circle outside } /* Any UL child of a UL*/
Although authors may specify 'list-style' information directly on list
item elements (e.g., LI in HTML), they should do so with care. The
following rules look similar, but the first declares a descendant
selector and the second a (more specific) child selector.
OL.alpha LI { list-style: lower-alpha } /* Any LI descendant of an OL */
OL.alpha > LI { list-style: lower-alpha } /* Any LI child of an OL */
Authors who use only the descendant selector may not achieve the
results they expect. Consider the following rules:
level 1
The desired rendering would have level 1 list items with 'lower-alpha'
labels and level 2 items with 'disc' labels. However, the cascading
order will cause the first style rule (which includes specific class
information) to mask the second. The following rules solve the problem
by employing a child selector instead:
OL.alpha > LI { list-style: lower-alpha }
UL LI { list-style: disc }
Another solution would be to specify 'list-style' information only on
the list type elements:
OL.alpha { list-style: lower-alpha }
UL { list-style: disc }
Inheritance will transfer the 'list-style' values from OL and UL
elements to LI elements. This is the recommended way to specify list
style information.
A URI value may be combined with any other value, as in:
UL { list-style: url(http://png.com/ellipse.png) disc }
In the example above, the 'disc' will be used when the image is
unavailable.
With a value of 'none', both 'list-style-type' and 'list-style-image'
are set to 'none':
UL { list-style: none }
The result is that no list-item marker is displayed.
_________________________________________________________________
_________________________________________________________________
18 Tables
Contents
* 18.1 Introduction to tables
* 18.2 The CSS table model
+ 18.2.1 Anonymous table boxes
* 18.3 Column selectors
* 18.4 Tables in the visual rendering model
+ 18.4.1 Caption position and alignment
* 18.5 Visual layout of table contents
+ 18.5.1 Row and column spans: 'column-span', and 'row-span'
+ 18.5.2 Table layers and transparency
+ 18.5.3 Table size algorithms: the 'table-layout' property
o Fixed table layout
o Automatic table layout
+ 18.5.4 Alignment of cell boxes
o Vertical alignment in a row
o Horizontal alignment in a column
+ 18.5.5 Dynamic row and column effects
* 18.6 Borders
+ 18.6.1 The separated borders model
o Borders around empty cells: the 'empty-cells' property
+ 18.6.2 The collapsing border model
o Border conflict resolution
+ 18.6.3 Border styles
* 18.7 Audio rendering of tables
+ 18.7.1 Speaking headers: the 'speak-header' property
18.1 Introduction to tables
Tables represent relationships between data. Authors specify these
relationships in the document language and specify their presentation
in CSS, in two ways: visually and aurally.
Authors may specify the visual rendering of a table as a rectangular
grid of cells. Rows and columns of cells may be organized into row
groups and column groups. Rows, columns, row groups, row columns, and
cells may have borders drawn around them (there are two border models
in CSS2). Authors may align data vertically or horizontally within a
cell and align data in all cells of a row or column.
Authors may also specify the aural rendering of a table; how headers
and data will be spoken. In the document language, authors may label
cells and groups of cells so that when rendered aurally, cell headers
are spoken before cell data. In effect, this "serializes" the table:
users browsing the table aurally hear a sequence of headers followed
by data.
Here is a simple three-row, three-column table described in HTML 4.0:
This is a simple 3x3 table
Header 1 Cell 1 Cell 2
Header 2 Cell 3 Cell 4
Header 3 Cell 5 Cell 6
This code creates one table (the TABLE element), three rows (the TR
elements), three header cells (the TH elements), and six data cells
(the TD elements). Note that the three columns of this example are
specified implicitly: there are as many columns in the table as
required by header and data cells.
The following CSS rule centers the text horizontally in the header
cells and present the data with a bold font weight:
TH { text-align: center; font-weight: bold }
The next rules align the text of the header cells on their baseline
and vertically centers the text in each data cell:
TH { vertical-align: baseline }
TD { vertical-align: middle }
The next rules specify that the top row will be surrounded by a 3px
solid blue border and each of the other rows will be surrounded by a
1px solid black border:
TABLE { border-spacing: none }
TR#row1 { border-top: 3px solid blue }
TR#row2 { border-top: 1px solid black }
TR#row3 { border-top: 1px solid black }
Note, however, that the borders around the rows overlap where the rows
meet. What color (black or blue) and thickness (1px or 3px) will the
border between row1 and row2 be? We discuss this in the section on
border conflict resolution.
The following rule puts the table caption above the table:
CAPTION { caption-side: top }
Finally, the following rule specifies that, when rendered aurally,
each row of data is to be spoken as a "Header, Data, Data":
TH { speak-header: once }
For instance, the first row would be spoken "Header1 Cell1 Cell2". On
the other hand, with the following rule:
TH { speak-header: always }
it would be spoken "Header1 Cell1 Header1 Cell2".
The preceding example shows how CSS works with HTML 4.0 elements; in
HTML 4.0, the semantics of the various table elements (TABLE, CAPTION,
THEAD, TBODY, TFOOT, COL, COLGROUP, TH, and TD) are well-defined. In
other document languages (such as XML applications), there may not be
pre-defined table elements. Therefore, CSS2 allows authors to "map"
document language elements to table elements via the 'display'
property. For example, the following rule makes the FOO element act
like an HTML TABLE element and the BAR element act like a CAPTION
element:
FOO { display : table }
BAR { display : table-caption }
We discuss the various table elements in the following section. In
this specification, the term table element refers to any element
involved in the creation of a table. An "internal" table element is
one that produces a row, row group, column, column group, or cell.
18.2 The CSS table model
The CSS table model is based on the HTML 4.0 table model, in which the
structure of a table closely parallels the visual layout of the table.
In this model, a table consists of an optional caption and any number
of rows of cells. The table model is said to be "row primary" since
authors specify rows, not columns, explicitly in the document
language. Columns are derived once all the rows have been specified --
the first cell of each row belongs to the first column, the second to
the second column, etc.). Rows and columns may be grouped structurally
and this grouping reflected in presentation (e.g., a border may be
drawn around a group of rows).
Thus, the table model consists of tables, captions, rows, row groups,
columns, column groups, and cells.
The CSS model does not require that the document language include
elements that correspond to each of these components. For document
languages (such as XML applications) that do not have pre-defined
table elements, authors must map document language elements to table
elements; this is done with the 'display' property. The following
'display' values assign table semantics to an arbitrary element:
table (In HTML: TABLE)
Specifies that an element defines a block-level table: it is a
rectangular block that participates in a block formatting
context.
inline-table (In HTML: TABLE)
Specifies that an element defines an inline-level table: it is
a rectangular block that participates in an inline formatting
context).
table-row (In HTML: TR)
Specifies that an element is a row of cells.
table-row-group (In HTML: TBODY)
Specifies that an element groups one or more rows.
table-header-group (In HTML: THEAD)
Like 'table-row-group', but for visual rendering, the row group
is always displayed before all other rows and rowgroups and
after any top captions.
table-footer-group (In HTML: TFOOT)
Like 'table-row-group', but for visual rendering, the row group
is always displayed after all other rows and rowgroups and
before any bottom captions.
table-column (In HTML: COL)
Specifies that an element describes a column of cells.
table-column-group (In HTML: COLGROUP)
Specifies that an element groups one or more columns.
table-cell (In HTML: TD, TH)
Specifies that an element represents a table cell.
table-caption (In HTML: CAPTION)
Specifies a caption for the table.
Elements with 'display' set to 'table-column' or 'table-column-group'
are not rendered (exactly as if they had 'display: none'), but they
are useful, because they may have attributes which induce a certain
style for the columns they represent.
The default style sheet for HTML 4.0 in the appendix illustrates the
use of these values for HTML 4.0:
TABLE { display: table }
TR { display: table-row }
THEAD { display: table-header-group }
TBODY { display: table-row-group }
TFOOT { display: table-footer-group }
COL { display: table-column }
COLGROUP { display: table-column-group }
TD, TH { display: table-cell }
CAPTION { display: table-caption }
User agents may ignore these 'display' property values for HTML
documents, since authors should not alter an element's expected
behavior.
18.2.1 Anonymous table boxes
Document languages other than HTML may not contain all the elements in
the CSS2 table model. In these cases, the "missing" elements must be
assumed in order for the table model to work. The missing elements
generate anonymous boxes according to the following rules:
1. Any table element will automatically generate necessary table
boxes around itself, consisting of at least three nested boxes
corresponding to a 'table'/'inline-table' element, a 'table-row'
element, and a 'table-cell' element.
2. If the parent of a 'table-cell' is not a 'table-row', a
'table-row' element will be assumed as its parent, and this
element will generate an anonymous box that spans all consecutive
'table-cell' siblings.
3. If the parent of a 'table-row' is not a 'table', 'inline-table',
or 'row-group' element, the 'table-row' will be assumed to have a
parent 'table' element that generates a box spanning all
consecutive siblings also requiring a 'table' parent.
4. If the parent of a 'table-row-group' is not a 'table' or
'inline-table', the 'table-row-group' will be assumed to have a
parent 'table' element that generates a box spanning all
consecutive siblings also requiring a 'table' parent.
5. 'table-cell' elements are inserted as children of a 'table-row'
element to contain consecutive children that are not 'table-cell'
elements.
In this XML example, a 'table' element is assumed to contain the HBOX
element:
George
4287
1998
because the associated style sheet is:
HBOX {display: table-row}
VBOX {display: table-cell}
In this example, three 'table-cell' elements are assumed to contain
the text in the ROWs. Note that the text is further encapsulated in
anonymous inline boxes, as explained in visual rendering model:
This is the top row.
This is the middle row.
This is the bottom row.
The style sheet is:
STACK {display: inline-table}
ROW {display: table-row}
D {display: inline; font-weight: bolder}
HTML user agents are not required to create anonymous boxes according
to the above rules.
18.3 Column selectors
Table cells may belong to two contexts: rows and columns. However, in
the source document cells are descendants of rows, never of columns.
Nevertheless, some aspects of cells can be influenced by setting
properties on columns.
The following properties apply to column and column-group elements:
'border'
The various border properties apply to columns only if
'border-collapse' is set to 'collapse' on the table element. In
that case, borders set on columns and column groups are input
to the conflict resolution algorithm that selects the border
styles at every cell edge.
'background'
The background properties set the background for cells in the
column, but only if both the cell and row have transparent
backgrounds. See "Table layers and transparency."
'width'
The 'width' property of the column only applies if the fixed
layout algorithm is selected on the 'table-layout' property.
'column-span'
The number of grid columns spanned by this column or column
group.
'visibility'
If the 'visibility' of a column is set to 'collapse', none of
the cells in the column are rendered, and cells that span into
other columns are clipped. In addition, the width of the table
is diminished by the width the column would have taken up. See
"Dynamic effects" below. Other values for 'visibility' have no
effect.
Here are some examples of style rules that set properties on columns.
The first two rules together implement the "rules" attribute of HTML
4.0 with a value of "cols". The third rule makes the "totals" column
blue, the final two rules shows how to make a column a fixed size, by
using the fixed layout algorithm.
COL {border-style: none solid}
TABLE {border-style: hidden}
COL.totals {background: blue}
TABLE {table-layout: fixed}
COL.totals {width: 5em}
18.4 Tables in the visual rendering model
In terms of the visual rendering model, a table may behave like a
block-level or replaced inline-level element.
In both cases, the table element generates an anonymous box that
contains the table box itself and the caption's box (if present). The
table and caption boxes retain their own content, padding, margin, and
border areas, and the dimensions of the rectangular anonymous box are
the smallest required to contain both. Vertical margins collapse where
the table box and caption box touch. Any repositioning of the table
must move the entire anonymous box, not just the table box, so that
the caption follows the table.
A table with a caption above it; both have margins and the margins
between them are collapsed, as is normal for vertical margins.
Diagram of a table with a caption above it; the bottom margin of the
caption is collapsed with the top margin of the table.
18.4.1 Caption position and alignment
'caption-side'
Value: top | bottom | left | right | inherit
Initial: top
Applies to: 'table-caption' elements
Inherited: yes
Percentages: N/A
Media: visual
This property specifies the position of the caption box with respect
to the table box. Values have the following meanings:
top
Positions the caption box above the table box.
bottom
Positions the caption box below the table box.
left
Positions the caption box to the left of the table box.
right
Positions the caption box to the right of the table box.
Captions above or below a 'table' element are rendered very much as if
they were a block element before or after the table, except that (1)
they inherit inheritable properties from the table, and (2) are not
considered to be a block box for the purposes of any 'compact' or
'run-in' element that may precede the table.
The width of a caption that is above or below a 'table' element is
computed as if the caption were a block-level child of the table's
parent. In other words, the width of the caption is independent of the
width of the table.
The width of a caption that is on the left or right side of the table
must be set explicitly. The default value ('auto') will result in the
narrowest possible box.
To align caption content horizontally within the caption box, use the
'text-align' property. For vertical alignment of captions on the left
or right side, use the 'vertical-align' property. The only meaningful
values in this case are 'top', 'middle', and 'bottom'. All other
values are treated the same as 'top'.
In this example, the 'caption-side' property places captions below
tables. The caption will be as wide as the parent of the table, and
caption text will be left-justified.
CAPTION { caption-side: bottom;
width: auto; /* default */
text-align: left }
The following example shows how to put a caption in the left margin.
The table itself is centered, by setting its left and right margins to
'auto', and the whole box with table and caption is shifted into the
left margin by the same amount as the width of the caption.
BODY {
margin-left: 8em
}
TABLE {
margin-left: auto;
margin-right: auto
}
CAPTION {
caption-side: left;
margin-left: -8em;
width: 8em;
text-align: right;
vertical-align: bottom
}
Assuming the width of the table is less than the available width, the
rendering will be similar to this:
A centered table with a caption in the left margin of the page
Diagram showing a centered table with the caption extending into the
left margin, as a result of a negative 'margin-left' property.
18.5 Visual layout of table contents
Like other elements of the document language, table elements generate
rectangular boxes with content, padding, border, and margin areas.
18.5.1 Row and column spans: 'column-span', and 'row-span'
'row-span'
Value: | inherit
Initial: 1
Applies to: 'table-cell' elements
Inherited: no
Percentages: N/A
Media: visual
This property specifies the number of rows spanned by a
cell.
'column-span'
Value: | inherit
Initial: 1
Applies to: 'table-cell', 'table-column', and
'table-column-group' elements
Inherited: no
Percentages: N/A
Media: visual
This property specifies the number of grid columns spanned
by a cell, column, or column group.
The visual layout of these boxes is governed by a rectangular,
irregular grid of rows and columns. Each box occupies a whole number
of grid cells, determined according to the following rules. These
rules do not apply to HTML 4.0 or earlier HTML versions; HTML imposes
its own limitations on row and column spans.
1. Each row box occupies one row of grid cells. Together, the row
boxes fill the table from top to bottom in the order they occur in
the source document (i.e., the table occupies exactly as many grid
rows as there are row elements).
2. A row group occupies the same grid cells as the rows it contains.
3. Columns are placed next to each other in the order they occur.
Each one occupies the number of grid columns given by its
'column-span' property. The first column may be either on the left
or on the right, depending on the value of the 'direction'
property of the table.
4. A column group occupies the same grid cells as the columns it
contains.
[Not true, need correct description.]
5. Structurally speaking, each cell belongs to one row and column;
this row and column determine the coordinates of the cell.
Visually, each cell occupies a rectangle of 'column-span' grid
cells wide and 'row-span' grid cells high. The top row of this
rectangle of grid cells must be the row specified by the cell's
parent. The rectangle must be as far to the left as possible, but
it may not overlap with any other cell, and must be to the right
of all cells in the same row that are earlier in the source
document. (If the 'direction' of the table is 'right-to-left',
interchange "left" and "right" in the previous sentence.)
6. Cells are 'row-span' high only if there are enough rows: a cell
cannot extend below the last row box; it is made shorter until it
fits.
Here is an example:
This table is in error. According to HTML 4.0, the rendering on the
left is allowed. However, CSS2 UAs must render this table as in the
figure on the right:
two renderings of an erroneous table
Two renderings of an erroneous HTML 4.0 table. The rendering on the
left is allowed by HTML 4.0, but in CSS2 the one on the right is
compulsory.
18.5.2 Table layers and transparency
For the purposes of finding the background of each table cell, the
different table elements may be thought of as being on six
superimposed layers. The background set on an element in one of the
layers will only be visible if the layers above it have a transparent
background.
schema of table layers
Schema of table layers.
1. The lowest layer is a single plane, representing the table box
itself. Like all boxes, it may be transparent.
2. The next layer contains the column groups. The columns groups are
as tall as the table, but they need not cover the whole table
horizontally.
3. On top of the column groups are the areas representing the column
boxes. Like column groups, columns are as tall as the table, but
need not cover the whole table horizontally.
4. Next is the layer containing the row groups. Each row group is as
wide as the table. Together, the row groups completely cover the
table from top to bottom.
5. The last but one layer contains the rows. The rows also cover the
whole table.
6. The topmost layer contains the cells themselves. As the figure
shows, although all rows contain the same number of cells, not
every cell may have specified content These "empty" cells are
transparent, letting lower layers shine through.
In the following example, the first row contains four cells, but the
second row contains no cells, and thus the table background shines
through, except where a cell from the first row spans into this row.
The following HTML code and style rules
might be rendered as follows:
Table with three empty cells in bottom row
Table with three empty cells in the bottom row.
18.5.3 Table size algorithms: the 'table-layout' property
CSS does not define an "optimal" layout for tables since, in many
cases, what is optimal is a matter of taste. CSS does define
constraints that user agents must respect when laying out a table.
User agents may use any algorithm they wish to do so, and are free to
prefer rendering speed over precision, except when the "fixed layout
algorithm" is selected.
'table-layout'
Value: auto | fixed | inherit
Initial: auto
Applies to: 'table' and 'inline-table' elements
Inherited: no
Percentages: N/A
Media: visual
The 'table-layout' property controls the algorithm used to lay out the
table cells, rows, and columns. Values have the following meaning:
fixed
Use the fixed table layout algorithm
auto
Use any automatic table layout algorithm
The two algorithms are described below.
Fixed table layout
With this (fast) algorithm, the horizontal layout of the table does
not depend on the contents of the cells; it only depends on the
table's width and the width of the columns.
The table's width is determined by the 'width' property. If the value
is 'auto', the table is as wide as the available horizontal space.
The width of each column is determined as follows:
1. A column element with a value other than 'auto' for the 'width'
property sets the width for that columns.
2. Otherwise, a cell in the first row with a value other than 'auto'
for the 'width' property sets the width for that column. If the
cell spans columns, the width is divided over the columns.
3. Any remaining columns equally divide the remaining space.
In this manner, the user agent lays out the first row of the table
immediately upon receiving the content. All subsequent rows have the
same widths of columns of cells; nothing in subsequent rows can affect
the widths of the columns. Any cell that has content that overflows
its dimensions uses the 'overflow' property to determine how to handle
the overflow content. However, a value of 'visible' will not increase
the cell box dimensions; cell content will flow into the adjacent
cell.
With this algorithm, the height of a row of cells may either be
computed dynamically (the 'auto' value), or may be set explicitly, in
which case overflow is handled in the same manner as with the width
dimension.
It is possible that the sum of the widths of the columns exceeds the
table's width. In that case the larger width is used as the actual
value of the table's 'width' property.
Automatic table layout
This is a multiple-pass algorithm in which a table width is given by
the width of its columns (and intervening borders). This algorithm
reflects the behavior of several popular HTML user agents at the
writing of this specification. UAs are not required to implement this
algorithm to determine the table layout in the case that
'table-layout' is 'auto'; they can use any other algorithm.
In this algorithm, the width of each column is based on the largest
unbreakable element in a cell in that column. This algorithm may be
inefficient since it may demand multiple passes and requires the user
agent to have access to all the content in the table before
determining the final layout.
For this algorithm, a value of 'auto' for the 'width' property for the
table element means that the final table width is computed
dynamically: it is the sum of the column widths and the borders
between them.
Column widths are determined as follows:
1. For each cell determine the minimum and maximum widths needed.
Cells with a given 'width' get a minimum width equal to the
greater of the specified width and the minimum needed width.
2. For each column determine a maximum and minimum width from the
cells with a colspan of 1. If the column has a 'width' greater
than the minimum over the cells, then the 'width' is used as the
minimum width for the column.
3. For each cell with a colspan of more than one, increase the
minimum and maximum widths of the columns it spans enough so the
combined minimum/maximum widths are at least those of the cell. If
possible, widen all spanned columns by approximately the same
amount.
Now we have a maximum and minimum width per column. We now determine
final column widths. Cell spacing is appropriately added into these
calculations.
If there is a table width given, and it is larger than the minimum
width needed, use it, and distribute the width over the columns in
some way.
Note that a table may thus be wider than its 'width' property.
If the table width is 'auto', there are three cases:
1. If the maximum needed width for the table is less than the width
of the table's containing block, use the maximum width.
2. If the minimum width needed is greater than the width of the
containing block, use the minimum width.
3. Otherwise, use the width of the containing block and distribute
the width over the columns in some way.
A percentage is relative to the table width. If the table's width is
'auto', a percentage represents a constraint on the column's width,
which a UA should try to satisfy. (Obviously, this is not always
possible: if the column's width is '110%', the constraint cannot be
satisfied.)
Note. In this algorithm, rows (and row groups) and columns (and column
groups) both constrain and are constrained by the dimensions of the
cells they contain. Setting the width of a column may indirectly
influence the height of a row, and vice versa.
18.5.4 Alignment of cell boxes
Cells may be aligned vertically (within a row) and horizontally
(within a column).
Note. Table cells may be relatively and absolutely positioned, but
this is not recommended: positioning and floating remove a box from
the flow, affecting table alignment.
Vertical alignment in a row
The height of a cell's box is constrained by the rows that contain it.
A cell may be smaller than a row, in which case its vertical alignment
is governed by the 'vertical-align' property (much as an inline box is
aligned within a line box).
Each cell's content has a baseline, a top, a middle, and a bottom, and
so does the row itself. The value of the 'vertical-align' property of
the cells determines on which of these lines they are aligned. In the
context of tables, values have the following meanings:
baseline
The baseline of the cell is put at the same height as the
baseline of the row (see below for the definition of baselines
of cells and rows)
top
The top of the cell box is aligned with the top of the row
bottom
The bottom of the cell box is aligned with the bottom of the
row
middle
The center of the cell is aligned with the center of the row
sub, super, text-top, text-bottom
These values do not apply to cells; the cell is aligned at the
baseline instead
The baseline of a cell is the baseline of the first line of text in
the cell. If there is no text, the baseline is the baseline of
whatever object is displayed in the cell, or, if it has none, the
bottom of the cell box. The maximum distance between the top of the
cell box and the baseline over all cells that have
'vertical-align:baseline' is used to set the baseline of the row. Here
is an example:
Example of vertically aligning the cells
Diagram showing the effect of various values of 'vertical-align' on
table cells.
Cell boxes 1 and 2 are aligned at their baselines. Cell box 2 has the
largest height above the baseline, so that determines the baseline of
the row. Note that if there is no cell box aligned at its baseline,
the row will not have (nor need) a baseline.
To avoid ambiguous situations, the alignment of cells proceeds in a
certain order. First the cells that are aligned on their baseline are
positioned. This will establish the baseline of the row. Next the
cells with alignment 'top' are positioned.
The row now has a top, possibly a baseline, and a provisional height,
which is the distance from the top to the lowest bottom of the cells
positioned so far. (See conditions on the cell padding below.)
If any of the remaining cells, those aligned at the bottom or the
middle, have a height that is larger than the current height of the
row, the height of the row will be increased to the maximum of those
cells, by lowering the bottom.
Finally the remaining cells are positioned.
Cells that are smaller than the height of the row will get extra
padding added at their top or bottom. As a result, the padding area at
the top and bottom of each cell box after positioning must be at least
as large as the 'padding' property specifies.
Horizontal alignment in a column
The horizontal alignment of a cell's contents within a cell box is
specified with the 'text-align' property.
Cell boxes in the same column may also be aligned horizontally along a
common axis, specified by the 'text-align' property. The
value of this property specifies how cell boxes in the same column
will align horizontally.
When the 'text-align' property for more than one cell in a column is
set to a the content of those cells is placed in such a way
that the beginnings of the first occurrence of the string in the
respective cells are placed directly over each other.
If a cell has a string-values 'text-align', but the string doesn't
occur in the cell, the cell is aligned at the end of its content.
Note that the strings do not have to be the same for each cell,
although they usually are.
Aligning text in this way is only useful if the text fits on one line.
The result is undefined if the text spans more than one line.
The following style sheet:
TD { text-align: "." }
TD:before { text-align: right; content: "$" }
will cause the column of dollar figures in the following HTML table:
Long distance calls
1.30
2.50
10.80
111.01
85.
90
.05
.06
to align along the decimal point. For fun, we have used the :before
pseudo-element to insert a dollar sign before each figure:
Long distance calls
$1.30
$2.50
$10.80
$111.01
$85.
$90
$.05
$.06
18.5.5 Dynamic row and column effects
The 'visibility' property takes the value 'collapse' for row, row
group, column, and column group elements. This value causes the entire
row or column to be removed from the display, and the space normally
taken up by the row or column to be made available for other content.
The suppression of the row or column, however, does not otherwise
affect the layout of the table. This allows dynamic effects to remove
table rows or columns without forcing a re-layout of the table in
order to account for the potential change in column constraints.
18.6 Borders
There are two distinct models for setting borders on table cells in
CSS. One is most suitable for so-called "2½D" borders around
individual cells, the other is suitable for borders that are
continuous from one end of the table to the other. Many border styles
can be achieved with either model, so it is often a matter of taste
which one is used.
'border-collapse'
Value: collapse | separate | inherit
Initial: collapse
Applies to: 'table' and 'inline-table' elements
Inherited: yes
Percentages: N/A
Media: visual
This property selects a table's border model. The value 'separate'
selects the separated borders border model. The value 'collapse'
selects the collapsing borders model. The models are described below.
18.6.1 The separated borders model
'border-spacing'
Value: ? | inherit
Initial: 0
Applies to: 'table' and 'inline-table' elements
Inherited: yes
Percentages: N/A
Media: visual
?
Use the separated borders model. In this case, the lengths
specify the distance that separate adjacent cell borders. If
one length is specified, it gives both the horizontal and
vertical spacing. If two are specified, the first gives the
horizontal spacing and the second the vertical spacing. Lengths
may not be negative.
In this model, each cell has an individual border. The
'border-spacing' property specifies the distance between the borders
of adjacent cells. This space is filled with the background of the
table element. Rows, columns, row groups, and column groups cannot
have borders (i.e., user agents must ignore the border properties for
those elements.
The table in the figure below could be the result of a style sheet
like this:
TABLE { border: outset 10pt;
border-collapse: separate;
border-spacing: 15pt }
TD { border: inset 5pt }
TD.special { border: inset 10pt } /* The top-left cell */
A table with border-spacing
A table with 'border-spacing' set to a length value. Note that each
cell has its own border, and the table has a separate border as well.
When this border model is used, the overall width of the table is the
sum of the cells plus the border spacing between all borders. See the
section on automatic table layout for more information about table
dimension calculations.
Borders around empty cells: the 'empty-cells' property
'empty-cells'
Value: borders | no-borders | inherit
Initial: borders
Applies to: 'table-cell' elements
Inherited: yes
Percentages: N/A
Media: visual
In the separated borders model, this property controls the rendering
of borders around cells that have no visible content. Empty cells and
cells with the 'visibility' property set to 'hidden' are considered to
have no visible content. Visible content includes " " and other
whitespace except ASCII CR ("\0D"), LF ("\0A"), tab ("\09"), and space
("\20").
When this property has the value 'borders', borders are drawn around
empty cells (like normal cells).
A value of 'no-borders' means that no borders are drawn around empty
cells. Furthermore, if all the cells in a row have a value of
'no-borders' and have no visible content, the entire row behaves as if
it had 'display : none'.
The following rule causes borders to be drawn around all cells:
TABLE { empty-cells: borders }
18.6.2 The collapsing border model
In the collapsing border model, it is possible to specify borders that
surround all or part of a cell, row, row group, column, and column
group. Borders for HTML's "rule" attribute can be specified this way.
Borders are centered on the grid lines between the cells. User agents
must find a consistent rule for rounding off in the case of an odd
number of discrete units (screen pixels, printer dots).
The diagram below shows how the width of the table, the widths of the
borders, the padding, and the cell width interact. Their relation is
given by the following equation, which holds for every row of the
table:
row-width = border-width0 + padding-left1 + width1 + padding-right1
+ border-width1 + padding-left2 +...+ padding-rightn +
border-widthn
Here n is the number of cells in the row, and border-widthi refers to
the border between cells i and i + 1.
Schema showing the widths of cells and borders and the padding of
cells
Schema showing the widths of cells and borders and the padding of
cells.
Note that in this model, the width of the table includes half the
table border. Also, in this model, a table doesn't have padding (but
does have margins).
Border conflict resolution
In the collapsing border model, borders at every edge of every cell
may be specified by border properties on a variety of elements that
meet at hat edge (cells, rows, row groups, columns, column groups, and
the table itself), and these borders may vary in width, style, and
color. The following rules determine which border style "wins" in case
of a conflict:
The rule of thumb is that at each edge the most "eye catching" border
style is chosen, except that any occurrence of the style 'hidden'
unconditionally turns the border off.
1. Borders with the 'border-style' of 'hidden' take precedence over
all other conflicting borders. Any border with this value
suppresses all borders at this location.
2. Borders with a style of 'none' have the lowest priority. Only if
the border properties of all the elements meeting at this edge are
'none' will the border be omitted (but note that 'none' is the
default value for the border style.)
3. If none of the styles is 'hidden' and at least one of them is not
'none', then narrow borders are discarded in favor of wider ones.
If several have the same 'border-width' than styles are preferred
in this order: 'double', 'solid', 'dashed', 'dotted', 'ridge',
'outset', 'groove', and the lowest: 'inset'.
4. If border styles differ only in color, then a style set on a cell
wins over one on a row, which wins over a row group, column,
column group and, lastly, table.
The following example illustrates the application of these precedence
rules. This style sheet:
TABLE { border-collapse: collapse;
border: 5px solid yellow; }
*#col1 { border: 1px solid black; }
TD { border: 5px solid red; }
TD.solid-blue { border: 11px solid blue; }
TD.solid-green { border: 7px solid green; }
with this HTML source:
would produce something like this:
[IMAGE HERE]
An example of a table with collapsed borders.
The next example shows a table with horizontal rules between the rows.
The top border of the table is set to 'hidden' to suppress the top
border of the first row. This implements the RULES="rows" attribute of
HTML 4.0.
TABLE[rules=rows] TR {border-top: solid}
TABLE[rules=rows] {border-collapse: collapse;
border-top: hidden}
Table with horizontal rules
Table with horizontal rules between the rows.
In this case the same effect can also be achieved without setting a
'hidden' border on TABLE, by addressing the first row separately.
Which method is preferred is a matter of taste.
TR:first-child {border-top: none}
TR {border-top: solid}
Here is another example of hidden collapsing borders:
Table with two omitted borders
Table with two omitted internal borders.
HTML source:
18.6.3 Border styles
Some of the values of the 'border-style' have different meanings in
tables than for other elements. In the list below they are marked with
an asterisk.
none
No border.
*hidden
Same as 'none', but in the collapsing border model, also
inhibits any other border (see the section on border
conflicts).
dotted
The border is a series of dots.
dashed
The border is a series of short line segments.
solid
The border is a single line segment.
double
The border is two solid lines. The sum of the two lines and the
space between them equals the value of 'border-width'.
groove
The border looks as though it were carved into the canvas.
ridge
The opposite of 'grove': the border looks as though it were
coming out of the canvas.
*inset
In the 2½D border model, the border makes the entire box look
as though it were embedded in the canvas. In the collapsing
border model, same as 'groove'.
*outset
In the 2½D border model, the border makes the entire box look
as though it were coming out of the canvas. In the collapsing
border model, same as 'ridge'.
18.7 Audio rendering of tables
When a table is spoken by a speech generator, the relation between the
data cells and the header cells must be expressed in a different way
than by horizontal and vertical alignment. Some speech browsers may
allow a user to move around in the 2-dimensional space, thus giving
them the opportunity to map out the spatially represented relations.
When that is not possible, the style sheet must specify at which
points the headers are spoken.
18.7.1 Speaking headers: the 'speak-header' property
'speak-header'
Value: once | always | inherit
Initial: once
Applies to: elements that have header information
Inherited: yes
Percentages: N/A
Media: aural
This property specifies whether table headers are spoken before every
cell, or only before a cell when that cell is associated with a
different header than the previous cell. Values have the following
meanings:
once
The header is spoken one time, before a series of cells.
always
The header is before every pertinent cell.
Each document language may have different mechanisms that allow
authors to specify headers. For example, in HTML 4.0 ([HTML40]), it is
possible to specify header information with three different attributes
("headers", "scope", and "axis"), and the specification gives an
algorithm for determining header information when these attributes
have not been specified.
Image of a table created in MS Word
Image of a table with header cells ("San Jose" and "Seattle") that are
not in the same column or row as the data they apply to.
This HTML example presents the money spent on meals, hotels and
transport in two locations (San Jose and Seattle) for successive days.
Conceptually, you can think of the table in terms of a n-dimensional
space. The headers of this space are: location, day, category and
subtotal. Some cells define marks along an axis while others give
money spent at points within this space. The markup for this table is:
Travel Expense Report
Meals
Hotels
Transport
subtotal
San Jose
25-Aug-97
37.74
112.00
45.00
26-Aug-97
27.28
112.00
45.00
subtotal
65.02
224.00
90.00
379.02
Seattle
27-Aug-97
96.25
109.00
36.00
28-Aug-97
35.00
109.00
36.00
subtotal
131.25
218.00
72.00
421.25
Totals
196.27
442.00
162.00
800.27
By providing the data model in this way, authors make it possible for
speech enabled-browsers to explore the table in rich ways, e.g. each
cell could be spoken as a list, repeating the applicable headers
before each data cell:
San Jose, 25-Aug-97, Meals: 37.74
San Jose, 25-Aug-97, Hotels: 112.00
San Jose, 25-Aug-97, Transport: 45.00
...
The browser could also speak the headers only when they change:
San Jose, 25-Aug-97, Meals: 37.74
Hotels: 112.00
Transport: 45.00
26-Aug-97, Meals: 27.28
Hotels: 112.00
...
_________________________________________________________________
_________________________________________________________________
19 User interface
Contents
* 19.1 Cursors: the 'cursor' property
* 19.2 User preferences for colors
* 19.3 User preferences for fonts
* 19.4 Dynamic outlines: the 'outline' property
+ 19.4.1 Outlines and the focus
* 19.5 Magnification
19.1 Cursors: the 'cursor' property
'cursor'
Value: [ [ ,]* [ auto | crosshair | default | pointer |
move | e-resize | ne-resize | nw-resize | n-resize | se-resize
| sw-resize | s-resize | w-resize| text | wait | help ] ] |
inherit
Initial: auto
Applies to: all elements
Inherited: yes
Percentages: N/A
Media: visual, interactive
This property specifies the type of cursor to be displayed for the
pointing device. Values have the following meanings:
auto
The UA determines the cursor to display based on the current
context.
crosshair
A simple crosshair (e.g., short line segments resembling a "+"
sign).
default
The platform-dependent default cursor. Often rendered as an
arrow.
pointer
The cursor is a pointer that indicates a link.
move
Indicates something is to be moved
*-resize
Indicates that the edge is to be moved.
text
Indicates text that may be selected. Often rendered as an
I-bar.
wait
A cursor to indicate that the program is busy and the user
should wait. Often rendered as a watch or hourglass.
help
Help is available for the object under the cursor. Often
rendered as a question mark or a balloon.
The user agent retrieves the cursor from the resource
designated by the URI. If the user agent cannot handle the
first cursor of a list of cursors, it should attempt to handle
the second, etc. If the user agent cannot handle any
user-defined cursor, it must use the generic cursor at the end
of the list.
P { cursor : url(mything.cur), url(second.csr), text; }
19.2 User preferences for colors
In addition to being able to assign pre-defined color values to text,
backgrounds, etc., CSS2 allows authors to specify colors in a manner
that integrates them into the user's graphic environment. Style rules
that take into account user preferences thus offer the following
advantages:
1. They produce pages that fit the user's defined look and feel.
2. They produce pages that may be more accessible as the current user
settings may be related to a disability.
The set of values defined for system colors is intended to be
exhaustive. For systems that do not have a corresponding value, the
specified value should be mapped to the nearest system attribute, or
to a default color.
The following lists additional values for color related CSS attributes
and their general meaning. Any color property (e.g., 'color' or
'background-color') can take one of the following names:
active-border
Active window border.
active-caption
Active window caption.
app-workspace
Background color of multiple document interface.
background
Desktop background.
button-face
Face color for three-dimensional display elements.
button-highlight
Dark shadow for three-dimensional display elements (for edges
facing away from the light source).
Shadow color for three-dimensional display elements.
button-text
Text on push buttons.
caption-text
Text in caption, size box, and scroll bar arrow box.
gray-text
Grayed (disabled) text. This color is set to #000 if the
current display driver does not support a solid gray color.
highlight
Item(s) selected in a control.
highlight-text
Text of item(s) selected in a control.
inactive-border
Inactive window border.
inactive-caption
Inactive window caption.
inactive-caption-text
Color of text in an inactive caption.
info-background
Background color for tooltip controls.
info-text
Text color for tooltip controls.
menu
Menu background.
menu-text
Text in menus.
scrollbar
Scroll bar gray area.
three-d-dark-shadow
Dark shadow for three-dimensional display elements.
three-d-face
Face color for three-dimensional display elements.
three-d-highlight
Highlight color for three-dimensional display elements.
three-d-light-shadow
Light color for three-dimensional display elements (for edges
facing the light source).
three-d-shadow
Dark shadow for three-dimensional display elements.
window
Window background.
window-frame
Window frame.
window-text
Text in windows.
For example, to set the foreground and background colors of a
paragraph to the same foreground and background colors of the user's
window, write the following:
P { color: windowtext; background-color: window }
19.3 User preferences for fonts
As for colors, authors may specify fonts in a way that makes use of a
user's system resources. Please consult the 'font' property for
details.
19.4 Dynamic outlines: the 'outline' property
At times, style sheet authors may want to create outlines around
visual objects such as buttons, active form fields, image maps, etc.,
to make them stand out. CSS2 outlines differ from borders in the
following ways:
1. Displaying or suppressing outlines does not cause reflow.
2. Outlines may be non-rectangular.
The outline properties control the style of these dynamic outlines.
'outline'
Value: <'outline-color'> || <'outline-style'> ||
<'outline-width'> | inherit
Initial: see individual properties
Applies to: all elements
Inherited: no
Percentages: N/A
Media: visual, interactive
'outline-width'
Value: | inherit
Initial: medium
Applies to: all elements
Inherited: no
Percentages: N/A
Media: visual, interactive
'outline-style'
Value: | inherit
Initial: none
Applies to: all elements
Inherited: no
Percentages: N/A
Media: visual, interactive
'outline-color'
Value: | invert | inherit
Initial: invert
Applies to: all elements
Inherited: no
Percentages: N/A
Media: visual, interactive
The outline created with the outline properties is drawn "over" a box,
i.e., the outline is always on top, and doesn't influence the position
or size of the box, or of any other boxes.
The outline is drawn starting just outside the border edge.
Outlines may be non-rectangular. For example, if the element is broken
across several lines, the outline is the minimum outline that encloses
all the element's boxes. In contrast to borders, the outline is not
open at the line box's end or start, but is always fully connected.
The 'outline-width' property accepts the same values as
'border-width'.
The 'outline-style' property accepts the same values as
'border-style', except that 'hidden' is not a legal outline style.
The 'outline-color' accepts all colors, as well as the keyword
'invert'. 'Invert' is expected to perform a color inversion on the
pixels on the screen. This is a common trick to ensure the focus
border is visible, regardless of color background.
The 'outline' property is a shorthand property, and sets all three of
'outline-style', 'outline-width', and 'outline-color'.
Note that the outline is the same on all sides. In contrast to
borders, there is no "outline-top" or "outline-left" property.
This specification does not define how multiple overlapping outlines
are drawn, or how outlines are drawn for boxes that are partially
obscured behind other elements.
Note. Since the focus outline does not affect formatting (i.e., no
space is left for it in the box model), it may well overlap other
elements on the page.
Here's an example of drawing a thick outline around a BUTTON element:
BUTTON { outline-width : thick }
Scripts may be used to dynamically change the width of the outline,
without provoking reflow.
19.4.1 Outlines and the focus
Graphical user interfaces may use outlines to tell the user which
element on the page has the focus. The focus is the subject of user
interaction in a document (e.g., for entering text, selecting a
button, etc.). User agents supporting the interactive media group must
keep track of where the focus lies and must also represent the focus.
This may be done by using dynamic outlines in conjunction with the
:focus pseudo-class.
For example, to draw a thick black line around an element when it has
the focus, and a thick red line when it is active, the following rules
can be used:
:focus {outline: thick solid black}
:active {outline: thick solid red}
19.5 Magnification
The CSS working group considers that the magnification of a document
or portions of a document should not be specified through style
sheets. User agents may support such magnification in different ways
(e.g., larger images, louder sounds, etc.)
When magnifying a page, UAs should preserve the relationships between
positioned elements. For example, a comic strip may be composed of
images with overlaid text elements. When magnifying this page, a user
agent should keep the text within the comic strip balloon.
_________________________________________________________________
_________________________________________________________________
20 Aural style sheets
Contents
* 20.1 Introduction to aural style sheets
* 20.2 Volume properties: 'volume'
* 20.3 Speaking properties: 'speak'
* 20.4 Pause properties: 'pause-before', 'pause-after', and 'pause'
* 20.5 Cue properties: 'cue-before', 'cue-after', and 'cue'
* 20.6 Mixing properties: 'play-during'
* 20.7 Spatial properties: 'azimuth' and 'elevation'
* 20.8 Voice characteristic properties: 'speech-rate',
'voice-family', 'pitch', 'pitch-range', 'stress', and 'richness'
* 20.9 Speech properties: 'speak-punctuation' and 'speak-numeral'
20.1 Introduction to aural style sheets
The aural rendering of a document, already commonly used by the blind
and print-impaired communities, combines speech synthesis and
"auditory icons." Often such aural presentation occurs by converting
the document to plain text and feeding this to a screen reader --
software or hardware that simply reads all the characters on the
screen. This results in less effective presentation than would be the
case if the document structure were retained. Style sheet properties
for aural presentation may be used together with visual properties
(mixed media) or as an aural alternative to visual presentation.
Besides the obvious accessibility advantages, there are other large
markets for listening to information, including in-car use, industrial
and medical documentation systems (intranets), home entertainment, and
to help users learning to read or who have difficulty reading.
When using aural properties, the canvas consists of a
three-dimensional physical space (sound surrounds) and a temporal
space (one may specify sounds before, during, and after other sounds).
The CSS properties also allow authors to vary the quality of
synthesized speech (voice type, frequency, inflection, etc.).
Example:
H1, H2, H3, H4, H5, H6 {
voice-family: paul;
stress: 20;
richness: 90;
cue-before: url("ping.au")
}
P.heidi {azimuth: center-left}
P.peter {azimuth: right}
P.goat {volume: x-soft}
This will direct the speech synthesizer to speak headers in a voice
called "paul" (cf. 'font-family'), on a flat tone, but in a very rich
voice. Before speaking the headers, a sound sample will be played from
the given URL. Paragraphs with class "heidi" will appear to come from
front left (if the sound system is capable of spatial audio), and
paragraphs of class "peter" from the right. Paragraphs with class
"goat" will be very soft.
20.2 Volume properties: 'volume'
'volume'
Value: | | silent | x-soft | soft |
medium | loud | x-loud | inherit
Initial: medium
Applies to: all elements
Inherited: yes
Percentages: relative to inherited value
Media: aural
Volume refers to the median volume of the waveform. In other words, a
highly inflected voice at a volume of 50 might peak well above that.
The overall values are likely to be human adjustable for comfort, for
example with a physical volume control (which would increase both the
0 and 100 values proportionately); what this property does is adjust
the dynamic range.
Values have the following meanings:
Any number between '0' and '100'. '0' represents the minimum
audible volume level and 100 corresponds to the maximum
comfortable level.
Percentage values are calculated relative to the inherited
value, and are then clipped to the range '0' to '100'.
silent
No sound at all. The value '0' does not mean the same as
'silent'.
x-soft
Same as '0'.
soft
Same as '25'.
medium
Same as '50'.
loud
Same as '75'.
x-loud
Same as '100'.
User agents should allow the values corresponding to '0' and '100' to
be set by the listener. No one setting is universally applicable;
suitable values depend on the equipment in use (speakers, headphones),
the environment (in car, home theater, library) and personal
preferences. Some examples:
* A browser for in-car use has a setting for when there is lots of
background noise. '0' would map to a fairly high level and '100'
to a quite high level. The speech is easily audible over the road
noise but the overall dynamic range is compressed. Cars with
better insulation might allow a wider dynamic range.
* Another speech browser is being used in an apartment, late at
night, or in a shared study room. '0' is set to a very quiet level
and '100' to a fairly quiet level, too. As with the first example,
there is a low slope; the dynamic range is reduced. The actual
volumes are low here, whereas they were high in the first example.
* In a quiet and isolated house, an expensive hi-fi home theater
setup. '0' is set fairly low and '100' to quite high; there is
wide dynamic range.
The same author style sheet could be used in all cases, simply by
mapping the '0' and '100' points suitably at the client side.
20.3 Speaking properties: 'speak'
'speak'
Value: normal | none | spell-out | inherit
Initial: normal
Applies to: all elements
Inherited: yes
Percentages: N/A
Media: aural
This property specifies whether text will be rendered aurally and if
so, in what manner (somewhat analogous to the 'display' property). The
possible values are:
none
Suppresses aural rendering so that the element requires no time
to render. Note, however, that descendants may override this
value and will be spoken. (To be sure to suppress rendering of
an element and its children, use the 'display' property).
normal
Uses language-dependent pronunciation rules for rendering an
element and its children.
spell-out
Spells the text one letter at a time (useful for acronyms and
abbreviations).
Note the difference between an element whose 'volume' property has a
value of 'silent' and an element whose 'speak' property has the value
'none'. The former takes up the same time as if it had been spoken,
including any pause before and after the element, but no sound is
generated.
20.4 Pause properties: 'pause-before', 'pause-after', and 'pause'
'pause-before'
Value: | | inherit
Initial: depends on user agent
Applies to: all elements
Inherited: no
Percentages: see prose
Media: aural
'pause-after'
Value: | | inherit
Initial: depends on user agent
Applies to: all elements
Inherited: no
Percentages: see prose
Media: aural
These properties specify a pause to be observed before (or after)
speaking an element's content. Values have the following meanings:
Expresses the pause in absolute time units (seconds and
milliseconds).
Refers to the inverse of the value of the 'speech-rate'
property. For example, if the speech-rate is 120 words per
minute (i.e., a word takes half a second, or 500ms) then a
'pause-before' of 100% means a pause of 500 ms and a
'pause-before' of 20% means 100ms.
The pause is inserted between the element's content and any
'cue-before' or 'cue-after' content.
Authors should use relative units to create more robust style sheets
in the face of large changes in speech-rate.
'pause'
Value: [ [ | ]{1,2} ] | inherit
Initial: depends on user agent
Applies to: all elements
Inherited: no
Percentages: see descriptions of 'pause-before' and
'pause-after'
Media: aural
The 'pause' property is a shorthand for setting 'pause-before' and
'pause-after'. If two values are given, the first value is
'pause-before' and the second is 'pause-after'. If only one value is
given, it applies to both properties.
Examples:
H1 { pause: 20ms } /* pause-before: 20ms; pause-after: 20ms */
H2 { pause: 30ms 40ms } /* pause-before: 30ms; pause-after: 40ms */
H3 { pause-after: 10ms } /* pause-before: ?; pause-after: 10ms */
20.5 Cue properties: 'cue-before', 'cue-after', and 'cue'
'cue-before'
Value: | none | inherit
Initial: none
Applies to: all elements
Inherited: no
Percentages: N/A
Media: aural
'cue-after'
Value: | none | inherit
Initial: none
Applies to: all elements
Inherited: no
Percentages: N/A
Media: aural
Auditory icons are another way to distinguish semantic elements.
Sounds may be played before and/or after the element to delimit it.
Values have the following meanings:
The URI must designate an auditory icon resource. If the URI
resolves to something other than an audio file, such as an
image, the resource should be ignored and the property treated
as if it had the value 'none'.
none
No auditory icon is specified.
For example:
A {cue-before: url(bell.aiff); cue-after: url(dong.wav) }
H1 {cue-before: url(pop.au); cue-after: url(pop.au) }
'cue'
Value: [ <'cue-before'> || <'cue-after'> ] | inherit
Initial: not defined for shorthand properties
Applies to: all elements
Inherited: no
Percentages: N/A
Media: aural
The 'cue' property is a shorthand for setting 'cue-before' and
'cue-after'. If two values are given, the first value is 'cue-before'
and the second is 'cue-after'. If only one value is given, it applies
to both properties.
The following two rules are equivalent:
H1 {cue-before: url(pop.au); cue-after: url(pop.au) }
H1 {cue: url(pop.au) }
If a user agent cannot render an auditory icon (e.g., the user's
environment does not permit it), we recommend that it produce an
alternative cue (e.g., popping up a warning, emitting a warning sound,
etc.)
20.6 Mixing properties: 'play-during'
'play-during'
Value: