Setting font properties will be among the most common uses of style
sheets. Unfortunately, there exists no well-defined and universally
accepted taxonomy for classifying fonts, and terms that apply to one
font family may not be appropriate for others. E.g. 'italic' is
commonly used to label slanted text, but slanted text may also be
labeled as being Oblique, Slanted, Incline, Cursive or
Kursiv. Therefore it is not a simple problem to map typical
font selection properties to a specific font.

Because there is no accepted, universal taxonomy of font
properties, matching of properties to font faces must be done
carefully. The properties 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 is
presented to each of them).

The User Agent makes (or accesses) a database of relevant CSS 2.1
properties of all the fonts of which the UA is aware.
If there are two fonts with exactly the same properties, the user
agent selects one of them.

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' property to
choose a tentative font family. The remaining properties are tested
against the family according to the matching criteria described with
each property. If there are matches for all the remaining properties,
then that is the matching font face for the given element.

If there is no matching font face within the 'font-family' being
processed by step 2, and if there is a next alternative 'font-family'
in the font set, then repeat step 2 with the next alternative
'font-family'.

If there is a matching font face, but it doesn't contain a glyph
for the current character, and if there is a next alternative
'font-family' in the font sets, then repeat step 2 with the next
alternative 'font-family'.

If there is no font within the family selected in 2, then use a
UA-dependent default 'font-family' and repeat step 2, using the best
match that can be obtained within the default font.
If a particular character cannot be displayed using this font,
then the UA has no suitable font for that character.
The UA should map each character for which it has no suitable font
to a visible symbol chosen by the UA, preferably a "missing character"
glyph from one of the font faces available to the UA.

(The above algorithm can be optimized to avoid having to revisit
the CSS 2.1 properties for each character.)

The per-property matching rules from (2) above are as follows:

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

'font-variant' is tried next. '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
upper case letters. A small-caps font may be synthesized by
electronically scaling uppercase letters from a normal font.
'normal' matches a font's normal (non-small-caps) variant. A font cannot fail to have a normal variant. A font
that is only available as small-caps shall be selectable as either a 'normal' face or a 'small-caps' face.

'font-weight' is matched next, it will
never fail. (See 'font-weight' below.)

'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 computed value of 'font-size'.

The value is a prioritized list of font family names and/or generic
family names. Unlike most other CSS properties, values are separated
by a comma to indicate that they are alternatives:

body { font-family: Gill, Helvetica, sans-serif }

Although many fonts provide the "missing character" glyph,
typically an open box, as its name implies this should not be
considered a match
for characters that cannot be found in the font. (It should,
however, be considered a match for U+FFFD, the "missing character"
character's code point).

In the example above, the last value is a generic family name. The
following generic families are defined:

'serif' (e.g. Times)

'sans-serif' (e.g. Helvetica)

'cursive' (e.g. Zapf-Chancery)

'fantasy' (e.g. Western)

'monospace' (e.g. Courier)

Style sheet designers are encouraged to offer a generic font family
as a last alternative. Generic font family names are keywords and must NOT be quoted.

If an unquoted font family name contains
parentheses, brackets, and/or braces, they must still be either balanced or
escaped per CSS grammar rules. Similarly, quote marks, semicolons,
exclamation marks and commas within unquoted font family names must be escaped.
Font names containing any such characters or 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.
Font family names that happen to be the same as a keyword value (e.g. 'initial', 'inherit', 'default', 'serif', 'sans-serif', 'monospace', 'fantasy', and 'cursive') must be quoted to prevent confusion with the keywords with the same names. UAs must not consider these keywords as matching the '<family-name>' type.

The 'font-style' property selects between normal (sometimes
referred to as "roman" or "upright"), italic and oblique faces within
a font family.

A value of 'normal' selects a font that is classified as 'normal'
in the UA's font database, while 'oblique' selects a font that is
labeled 'oblique'. A value of 'italic' selects a font that is labeled
'italic', or, if that is not available, one labeled 'oblique'.

The font that is labeled 'oblique' in the UA's font database may
actually have been generated by electronically slanting a normal font.

Fonts with Oblique, Slanted or Incline in their names will
typically be labeled 'oblique' in the UA's font database. Fonts with
Italic, Cursive or Kursiv in their names will
typically be labeled 'italic'.

h1, h2, h3 { font-style: italic }
h1 em { font-style: normal }

In the example above, emphasized text within 'H1' will appear in a
normal face.

Another type of variation within a font family is the small-caps.
In a small-caps font the lower case letters look similar to the
uppercase ones, but in a smaller size and with slightly different
proportions. The 'font-variant' property selects that font.

A value of 'normal' selects a font that is not a small-caps font,
'small-caps' selects a small-caps font. It is acceptable (but not
required) in CSS 2.1 if the small-caps font is a created by taking a
normal font and replacing the lower case letters by scaled uppercase
characters. As a last resort, uppercase letters will be used as
replacement for a small-caps font.

The following example results in an 'H3' element in small-caps,
with any emphasized words in oblique, and any emphasized words within
an 'H3' oblique small-caps:

h3 { font-variant: small-caps }
em { font-style: oblique }

There may be other variants in the font family as well, such as
fonts with old-style numerals, small-caps numerals, condensed or
expanded letters, etc. CSS 2.1 has no properties that select those.

Note: insofar as this property causes text to be
transformed to uppercase, the same considerations as for 'text-transform' apply.

The 'font-weight' property selects the weight of the font. The
values '100' to '900' form an ordered sequence, where each number
indicates a weight that is at least as dark as its predecessor. The
keyword 'normal' is synonymous with '400', and 'bold' is synonymous
with '700'. Keywords other than 'normal' and 'bold' have been shown to
be often confused with font names and a numerical scale was therefore
chosen for the 9-value list.

The 'bolder' and 'lighter' values select font weights that are
relative to the weight inherited from the parent:

strong { font-weight: bolder }

Child elements inherit the resultant weight, not the keyword value.

Fonts (the font data) typically have one or more properties whose
values are names that are descriptive of the "weight" of a font. There
is no accepted, universal meaning to these weight names. Their primary
role is to distinguish faces of differing darkness within a single
font family. Usage across font families is quite variant; for example,
a font that one might think of as being bold might be described as
being Regular, Roman, Book, Medium, Semi- or DemiBold,
Bold, or Black, depending on how black the "normal" face
of the font is within the design. Because there is no standard usage
of names, the weight property values in CSS 2.1 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 darkness
within that family. 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
(like 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.

The following two examples show typical mappings.

Assume four weights in the "Rattlesnake" family, from lightest to
darkest: Regular, Medium, Bold, Heavy.

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 "Ice Prawn ExtraBlack".

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)

Since the intent of the relative keywords 'bolder' and 'lighter' is
to darken or lighten the face within the family and because a
family may not have faces aligned with all the symbolic weight values,
the matching of 'bolder' is to the next darker face available on the
client within the family and the matching of 'lighter' is to the next
lighter face within the family. To be precise, the meaning of the
relative keywords 'bolder' and 'lighter' is as follows:

'bolder' selects 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' is similar, but works in the opposite direction: it
selects the next lighter keyword with a different font from the
inherited one, unless there is no such font, in which case it selects
the next lighter numerical value (and keeps the font unchanged).

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, while others may have eight face weights.
There is no guarantee on how a UA will map font faces within a family
to weight values. The only guarantee is that a face of a given value
will be no less dark than the faces of lighter values.

The computed value of "font-weight" is either:

one of the legal number values, or

one of the legal number values combined with one or more of the
relative values (bolder or lighter). This type of computed values
is necessary to use when the font in question does not have all
weight variations that are needed.

CSS 2.1 does not specify how the computed value of font-weight is
represented internally or externally.

An <absolute-size> keyword is an index to a table of font
sizes computed and kept by the UA. Possible values are:

[ xx-small | x-small | small | medium | large | x-large | xx-large ]

The following table provides user agent guidelines for the absolute-size
scaling factor and their mapping to HTML heading and absolute font-sizes. The
'medium' value is used as the reference middle value. The user agent may fine
tune these values for different fonts or different types of display devices.

CSS absolute-size values

xx-small

x-small

small

medium

large

x-large

xx-large

scaling factor

3/5

3/4

8/9

1

6/5

3/2

2/1

3/1

HTML headings

h6

h5

h4

h3

h2

h1

HTML font sizes

1

2

3

4

5

6

7

Different media may need different scaling factors. Also, the UA
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 1. To preserve readability, a UA applying
these guidelines should nevertheless avoid creating font-size resulting
in less than 9 pixels per EM unit on a computer display.

Note 2. In CSS1, the suggested
scaling factor between adjacent indexes was 1.5 which user experience
proved to be too large. In CSS2, the suggested scaling factor for computer
screen between adjacent indexes was 1.2 which still created issues for the small
sizes. The new scaling factor varies between each index to provide better
readability.

A <relative-size> 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 UA is free to interpolate between
table entries or round off to the closest one. The UA may have to
extrapolate table values if the numerical value goes beyond the
keywords.

Length and percentage values should not take the font size table
into account when calculating the font size of the element.

Negative values are not allowed.

On all other properties, 'em' and 'ex' length values refer to the
computed font size of the current element. On the 'font-size' property, these
length units refer to the computed font size of the parent element.

Note that an application may reinterpret an explicit size,
depending on the context. E.g., inside a VR scene a font may get a
different size because of perspective distortion.

All font-related properties are first reset to their initial values,
including those listed in the preceding paragraph.
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.

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 refers to the font size of the element itself.

In the first three rules above, the 'font-style', 'font-variant'
and 'font-weight' are not explicitly mentioned, which means they are
all three set to their initial value ('normal'). 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), the 'line-height' (120% times
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 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 'small-caption'
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.

If the font used for dropdown menus on a particular system
happened to be, for example, 9-point Charcoal, with a weight of 600, then P
elements that were descendants of BUTTON would be displayed as if
this rule were in effect:

button p { font: 600 9px Charcoal }

Because the 'font' shorthand
property resets any property not explicitly given a value
to its initial value, this has the same effect as this declaration: