CSS Fonts Module Level 3

Abstract

This CSS3 module describes how font properties are specified and how font resources are loaded dynamically. The contents of this specification are a consolidation of content previously divided into CSS3 Fonts and CSS3 Web Fonts modules.

Status of this document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

The (archived) public mailing list www-style@w3.org (see instructions) is preferred for discussion of this specification. When sending e-mail, please put the text “css3-fonts” in the subject, preferably like this: “[css3-fonts] …summary of comment…”

This document was produced by the CSS Working Group (part of the Style Activity).

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Table of contents

• 1 Introduction
• 2 Typography Background
• 3 Font properties
  • 3.1 Font family: the ‘font-family’ property
    • 3.1.1 Generic font families
  • 3.2 Font weight: the ‘font-weight’ property
  • 3.3 Font width: the ‘font-stretch’ property
  • 3.4 Font style: the ‘font-style’ property
  • 3.5 Small caps: the ‘font-variant’ property
  • 3.6 Font size: the ‘font-size’ property
  • 3.7 Relative sizing: the ‘font-size-adjust’ property
  • 3.8 Shorthand font property: the ‘font’ property
• 4 Font resources
  • 4.1 The @font-face rule
  • 4.2 Font family: the ‘font-family’ descriptor
  • 4.3 Font reference: the ‘src’ descriptor
  • 4.4 Font property descriptors: the ‘font-style’, ‘font-weight’, ‘font-stretch’ descriptors
  • 4.5 Character range: the ‘unicode-range’ descriptor
• 5 Font matching algorithm
• Appendix A: Mapping font features to CSS properties
• Appendix B: Font licensing issues
• Acknowledgments
• References
  • Normative
  • Informative
• Index
• Property index

1 Introduction

A font provides a resource containing the visual representation of characters. At a minimum it contains information that maps character codes to shapes (called glyphs) for displaying these characters. Fonts sharing a common design style are commonly grouped into font families classified by a set of standard font properties. Within a family, the shape displayed for a given character can vary by stroke weight, slant or relative width, among others. A given font face is described by a unique combination of these properties. For a given range of text, CSS font properties are used to select a font family and a specific font face within that family to be used when rendering that text. As a simple example, to use the bold form of Helvetica one could use:

body { 
    font-family: Helvetica; 
    font-weight: bold; 
}

Font resources may be local, installed on the system on which a user agent is running, or downloadable. For local font resources descriptive information can be obtained directly from the font resource. For downloadable font resources (sometimes referred to as web fonts), the descriptive information is included with the reference to the font resource.

Families of fonts typically don't contain a single face for each possible variation of font properties. The CSS font selection mechanism describes how to match a given set of CSS font properties to a given font face.

2 Typography Background

This section is included as background for some of the problems and situations that are described in other sections. It should be viewed as informative only.

Typographic traditions vary across the globe so there is no unique way to classify all fonts across languages and cultures. For even common Latin letters, wide variations are possible:

One character, many glyph variations

Differences in the anatomy of letterforms is one way to distinguish fonts. For Latin fonts, flourishes at the ends of a character's main strokes, or serifs, can distinguish a font from those without. Similar comparisons exist in non-Latin fonts between fonts with tapered strokes and those using primarily uniform strokes:

Letterforms with and without serifs

Similar groupings for Japanese typefaces

Fonts contain letterforms and the data needed to map characters to these letterforms. Often this may be a simple one-to-one mapping but more complex mappings are also possible. The use of combining diacritic marks creates many variations for an underlying letterform:

Variations with diacritic marks

A sequence of characters can be represented by a single glyph known as a ligature:

Ligature example

Visual transformations based on textual context like this may be a stylistic option for European languages but are required to correctly render languages like Arabic; the lam and alef characters below must be combined when they exist in sequence:

Required Arabic ligature

The relative complexity of these shaping transformations requires additional data within the font.

Sets of font faces with various stylistic variations are often grouped together into font families. In the simplest case a regular face is supplemented with bold and italic faces but much more extensive groupings are possible. Variations in the thickness of letterform strokes, or the weight, or the overall proportions of the letterform, or the width, are most common. In the example below, each letter uses a different font face within the Univers font family. The width used increases from top to bottom and the weight increases from left to right:

Weight and width variations within a single font family

Creating fonts that support multiple scripts is a difficult task; designers need to understand the cultural traditions surrounding the use of type in different scripts and come up with letterforms that somehow share a common theme. Many languages often share a common script and each of these languages may have noticeable stylistic differences. The Arabic script is shared by Persian and Urdu and Cyrillic is used with many languages, not just Russian.

Fonts provide a character map that details the set of characters for they have glyphs. If a document contains characters not supported by a specified font, a user agent may revert to a system font fallback procedure to find glyphs to render these characters correctly. If no font can be found, some form of "missing glyph" character is rendered by the user agent. Often these are the result of authors failing to explicitly indicate the encoding used by a document.

3 Font properties

The particular font face used to render a character is determined by the font family and other font properties that apply to a given element. This structure allows settings to be varied independent of each other.

3.1 Font family: the ‘font-family’ property

This property specifies a prioritized list of font family names or generic family names. A user agent iterates through the list of family names until it matches an available font that contains a glyph for the character to be rendered. This allows for differences in available fonts across across platforms and for differences in the range of characters supported by individual fonts.

A font family name only specifies a name given to a set of font faces, it does not specify an individual face. Given the availability of the fonts below, Futura would match but Futura Medium would not:

Family and individual face names

Some font formats support the use of multiple family names for different localizations. User agents should recognize any of these names independent of the underlying platform localization, system API used or document encoding:

Localized family names

Consider the example below:

body { 
    font-family: Helvetica, Verdana, sans-serif; 
}

If Helvetica is available it will be used when rendering. If neither Helvetica or Verdana is present, then the user agent defined sans serif font will be used.

There are two types of font family names:

<family-name>

The name of a font family of choice such as Helvetica or Verdana in the previous example. Font family names containing more than one word should be quoted. If quoting is omitted, whitespace characters before and after the font family name are ignored and any sequence of whitespace characters inside the font name is converted to a single space. Depending upon the font format used, font family names may be case-sensitive.

<generic-family>

The following generic family keywords are defined: ‘serif’, ‘sans-serif’, ‘cursive’, ‘fantasy’, and ‘monospace’. These keywords can be used as a general fallback mechanism when an author's desired font choices are not available. As keywords, they should not be quoted. Authors are encouraged to append a generic font family as a last alternative for improved robustness.

3.1.1 Generic font families

All five generic font families are defined to exist in all CSS implementations (they need not necessarily map to five distinct actual fonts). 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), Batang (Korean). Any font that is so described may be used to represent the generic ‘serif’ family.

Sample serif fonts

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), or Gulim (Korean). Any font that is so described may be used to represent the generic ‘sans-serif’ family.

Sample sans-serif fonts

cursive

Glyphs in cursive fonts 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. 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.

Sample cursive fonts

fantasy

Fantasy fonts are primarily decorative fonts that contain playful representations of characters. These do not include Pi or Picture fonts which do not represent actual characters.

Sample fantasy fonts

monospace

The sole criterion of a monospace font is that all glyphs have the same fixed width. This is often used to render samples of computer code.

Sample monospace fonts

3.2 Font weight: the ‘font-weight’ property

The ‘font-weight’ property specifies weight of glyphs in the font, their degree of blackness or stroke thickness.

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. These roughly correspond to the commonly used weight names below:

• 100 - Thin
• 200 - Extra Light (Ultra Light)
• 300 - Light
• 400 - Normal
• 500 - Medium
• 600 - Semi Bold (Demi Bold)
• 700 - Bold
• 800 - Extra Bold (Ultra Bold)
• 900 - Black (Heavy)

normal

Same as ‘400’.

bold

Same as ‘700’.

bolder

Specifies the weight of the face bolder than the inherited value.

lighter

Specifies the weight of the face lighter than the inherited value.

Font formats that use a scale other than a nine step scale should map their scale onto the CSS scale so that 400 roughly corresponds with a face that would be labeled as Regular, Book, Roman and 700 roughly matches a face that would be labeled as Bold. Or weights may be inferred from the style names, ones that correspond roughly with the scale above. The scale is relative, so a face with a larger weight value should never appear lighter. If style names are used to infer weights, care should be taken to handle variations in style names across locales.

Quite often there are only a few weights available for a particular font family. When a weight is specified for which no face exists, a face with a nearby weight is used. In general, bold weights map to faces with heavier weights and light weights map to faces with lighter weights (see the font matching section below for a precise definition). The examples here illustrate which face is used for different weights, grey indicates a face for that weight does not exist so a face with a nearby weight is used:

Weight mappings for a font family with 400, 700 and 900 weight faces

Weight mappings for a font family with 300 and 600 weight faces

Although not well-loved by typographers, bold faces are often synthesized by user agents for faces that lack actual bold faces. For the purposes of style matching, these faces should be treated as if they exist within the family.

Values of ‘bolder’ and ‘lighter’ indicate values relative to the weight of the parent element. Based on the inherited weight value, the weight used is calculated using the chart below. Child elements inherit the calculated weight, not a value of ‘bolder’ or ‘lighter’.

The table above is equivalent to selecting the next relative bolder or lighter face, given a font family containing normal and bold faces along with a thin and a heavy face. Authors who desire finer control over the exact weight values used for a given element should use numerical values instead of relative weights.

3.3 Font width: the ‘font-stretch’ property

The ‘font-stretch’ property selects a normal, condensed, or expanded face from a font family. Absolute keyword values have the following ordering, from narrowest to widest:

• Ultra Condensed
• Extra Condensed
• Condensed
• Semi Condensed
• Normal
• Semi Expanded
• Expanded
• Extra Expanded
• Ultra Expanded

The scale is relative, so a face with a font-stretch value higher in the list above should never appear wider. When a face does not exist for a given width, normal or condensed values map to a narrower face, otherwise a wider face. Conversely, expanded values map to a wider face, otherwise a narrower face. The figure below shows how the nine font-stretch property settings affect font selection for font family containing a variety of widths, grey indicates a width for which no face exists and a different width is substituted:

Width mappings for a font family with condensed, normal and expanded width faces

Values of ‘wider’ and ‘narrower’ indicate values relative to the width of the parent element. Based on the inherited font-stretch value, the width used is calculated using the chart below. Child elements inherit the calculated width value, not a value of ‘wider’ or ‘narrower’.

Issue: relative width values wider, narrower are being considered for removal.

3.4 Font style: the ‘font-style’ property

The ‘font-style’ property allows italic or oblique faces to be selected. Italic forms are generally cursive in nature while oblique faces are typically sloped versions of the regular face. Oblique faces can be simulated by artificially sloping the glyphs of the regular face. Compare the artificially sloped renderings of Palatino ‘a’ and Baskerville ‘N’ in grey with the actual italic versions:

Artificial sloping versus real italics

A value of ‘normal’ selects a face that is classified as ‘normal’, 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’. If no italic or oblique faces is available, an oblique face can by synthesized by rendering the normal face with a sloping transformation applied.

Many scripts lack the tradition of mixing a cursive form within text rendered with a normal face. Chinese, Japanese and Korean fonts almost always lack italic or oblique faces. Fonts that support a mixture of scripts will sometimes omit specific scripts such as Arabic from the set of glyphs supported in the italic face. User agents should be careful about making character map assumptions across faces.

3.5 Small caps: the ‘font-variant’ property

• small-caps
• used to select alternate glyphs if available in font
• can be simulated using sized versions of uppercase glyphs

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 that are unicameral (having only one case, as with most of the world's writing systems). Values have the following meanings:

normal

Specifies a face 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.

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.

3.6 Font size: the ‘font-size’ property

This property indicates the desired height of glyphs from the font. For scalable fonts, the font-size is a scale factor applied to the EM unit of the font. (Note that certain glyphs may bleed outside their EM box.) For non-scalable fonts, the font-size is converted into absolute units and matched against the declared font-size of the font, using the same absolute coordinate space for both of the matched values. Values have the following meanings:

<absolute-size>

An <absolute-size> 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 ]

<relative-size>

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

<length>

A length value specifies an absolute font size (that is independent of the user agent's font table). Negative lengths are illegal.

<percentage>

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 following table provides user agent's guideline for the absolute-size scaling factor and their mapping to XHTML 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.

Note 1. To preserve readability, an 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 a better readability.

The actual value [link to Cascading module] 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 compound).

p { font-size: 12pt; }
blockquote { font-size: larger }
em { font-size: 150% }
em { font-size: 1.5em }

3.7 Relative sizing: the ‘font-size-adjust’ property

For any given font size, the apparent size and legibility of text varies across fonts. For scripts such as Latin or Cyrillic that distinguish between upper and lowercase letters, the relative height of lowercase letters compared to their uppercase counterparts is a determining factor of legibility. This is commonly referred to as the aspect value. Precisely defined, it is equal to the x-height of a font divided by the font size.

In situations where font fallback occurs, fallback fonts may not share the same aspect ratio as the desired font family and will thus appear less readable. The font-size-adjust property is a way to preserve the readability of text when font fallback occurs. It does this by adjusting the font-size so that the x-height is the same irregardless of the font used.

p { 
    font-family: Verdana, Futura, Times; 
}

<p>Lorem ipsum dolor sit amet, ...</p>

How text rendered in each of these fonts compares is shown below, the columns show text rendered in Verdana, Futura and Times. The same font-size value is used across cells within each row and red lines are included to show the differences in x-height. In the upper half each row is rendered in the same font-size value. The same is true for the lower half but in this half the font-size-adjust property is also set so that the actual font size is adjusted to perserve the x-height across each row. Note how small text remains relatively legible across each row in the lower half.

Text with and without the use of font-size-adjust

This property allows authors to specify an aspect value for an element that will effectively preserve the x-height of the first choice font, whether it is substituted or not. Values have the following meanings:

none

Do not preserve the font's x-height.

<number>

Specifies the aspect value used in the calculation below to calculate the adjusted font size:

c  =  ( a / a' ) s 

where:

s  =  font-size value
a  =  aspect value as specified by the font-size-adjust property
a' =  aspect value of actual font
c  =  adjusted font-size to use

This value applies to any font that is selected but in typical usage it should be based on the aspect value of the first font in the font-family list. If this is specified accurately, the (a/a') term in the formula above is effectively 1 for the first font and no adjustment occurs. If the value is specified inaccurately, text rendered using the first font in the family list will display differently in older user agents that don't support font-size-adjust.

Authors can calculate the aspect value for a given font by comparing spans with the same content but different font-size-adjust properties. If the same font-size is used, the spans will match when the font-size-adjust value is accurate for the given font.

Two spans with borders are used to determine the aspect value of a font. The font-size is the same for both spans but the font-size-adjust property is specified only for the right span. Starting with a value of 0.5, the aspect value can be adjusted until the borders around the two letters line up.

p {
    font-family: Futura;
    font-size: 500px;
}

span {
    border: solid 1px red;
}

.adjust {
    font-size-adjust: 0.5;
}

<p><span>b</span><span class="adjust">b</span></p>

Futura with an aspect value of 0.5

The box on the right is a bit bigger than the one on the left, so the aspect value of this font is something less than 0.5. Adjust the value until the boxes align.

3.8 Shorthand font property: the ‘font’ property

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.

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 12pt "Helvetica Nue", serif; font-stretch: condensed }

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.

button { font: 300 italic 1.3em/1.7em "FB Armada", sans-serif }
button p { font: menu }
button p em { font-weight: bolder }

button p { font: 600 9pt Charcoal }

button p {
  font-style: normal;
  font-variant: normal;
  font-weight: 600;
  font-size: 9pt;
  line-height: normal;
  font-family: Charcoal
} 

4 Font resources

4.1 The @font-face rule

The @font-face rule allows for linking to fonts that are automatically activated when needed. This permits authors to work around the limitation of "web-safe" fonts, allowing for consistent rendering independent of the fonts available in a given user's environment. A set of font descriptors define the location of a font resource, either locally or externally, and the style characteristics of an individual face. Multiple @font-face rules can be used to construct font families with a variety of faces. Using CSS font matching rules, a user agent can selectively download only those faces that are needed for a given piece of text.

The general form of an @font-face at-rule is:

@font-face { <font-description> }

where <font-description> 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. There is no notion of which elements the descriptors apply to or whether the values are inherited by child elements. When a given descriptor occurs multiple times in a given @font-face rule, only the last specified value is used, all prior values for that descriptor are ignored.

@font-face {
  font-family: Gentium;
  src: url(http://site/fonts/Gentium.ttf);
}

p { font-family: Gentium, serif; }

A given set of @font-face rules define a set of fonts available to containing documents. Multiple rules can be used to define a family with a large set of faces. When font matching is done fonts defined using these rules are considered before other available fonts on a system.

Downloaded fonts are only available to documents that reference them, they should not be made available to other applications or other documents. User agent implementors might consider it convenient to use downloaded fonts when rendering characters in other documents for which no other available font exists as part of the system font fallback procedure. This however leads to non-deterministic rendering patterns where the appearance of a page effectively becomes a function of browsing history.

User agents which do not understand the @font-face rule encounter the opening curly bracket and ignore forward until the closing curly bracket. This at-rule conforms with the forward-compatible parsing requirement of CSS, parsers may ignore these rules without error. Any descriptors that are not recognized or implemented by a given user agent must be ignored. @font-face rules require a font-family and src descriptor, if either of these are missing the @font-face should be ignored.

In cases where user agents have limited platform resources or implement the ability to disable downloadable font resources, @font-face rules should simply be ignored; the behavior of individual descriptors as defined in this specification should not be altered.

4.2 Font family: the ‘font-family’ descriptor

This descriptor defines the font family name that will be used in all CSS font family name matching, overriding font family names contained in the underlying font data. If the font family name is the same as a font family available in a given user's environment, it effectively hides the underlying font for documents that use the stylesheet. This permits a web author to freely choose font-family names without worrying about conflicts with font family names present in a given user's environment. Errors loading font data do not affect font name matching behavior. User agents that apply platform font aliasing rules to font family names defined via @font-face rules are considered non-conformant.

4.3 Font reference: the ‘src’ descriptor

This descriptor specifies the resource containing font data. It is required, whether the font is downloadable or locally installed. It's value is a prioritized, comma-separated list of external references or locally installed font face names. When a font is needed the user agent iterates over the set of references listed, using the first one it can successfully activate. Fonts containing invalid data are treated as if they were not found, the user agent loads the next font in the list.

External references consist of a URI, followed by an optional hint regarding the format of the font resource referenced by that URI. The format hint contains a comma-separated list of format strings that denote well-known font formats. Conformant user agents should skip downloading a font resource if the format hints indicate only unsupported or unknown font formats. If no format hints are supplied, the user agent should download the font resource.

An initial list of format strings defined by this specification and representing formats likely to be used by implementations on various platforms is:

Given the overlap in common usage between TrueType and OpenType, for the purpose of a format hint "truetype" and "opentype" should be considered as synonymous; a format hint of "opentype" does not imply that the font contains Postscript CFF style glyph data or that it contains OpenType layout information (see Appendix A for more background on this). The "truetype-aat" string indicates that a font contains Apple Advanced Typography tables so user agents on platforms that do not support these tables should treat this format as unsupported. This allows authors to provide multiple fonts for rendering complex scripts such as Arabic or Devanagari that require platform-specific font data.

Issue: does a public registry need to be established for these hints?

  src: url(http://site/fonts/font.otf);

  src: url(../fonts/LateefRegAAT.ttf) format("truetype-aat"), 
       url(../fonts/LateefRegOT.ttf) format("opentype");

  src: url(DoulosSILR.ttf) format("opentype","truetype-aat");

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 rule. In the case of SVG fonts, the URL points to an element within a document containing SVG font definitions. If the element reference is omitted, a reference to the first defined font is implied.

The locally installed <font-face-name> is a format-specific string that uniquely identifies a single font face within a larger family. For TrueType and OpenType fonts, the full font name as defined in the font name table is used to reference a given face. Additionally, for TrueType and OpenType fonts user agents may optionally support Postscript name lookup on platforms where that is appropriate. The notation for a <font-face-name> is the unique font face name enclosed by "local(" and ")". The name can optionally be enclosed in quotes. This also allows for referencing faces that belong to larger families that cannot otherwise be referenced. If a font face with a given full font name or Postscript name is not found, the user agent loads the next font in the list, platform substitutions for the font should not be used.

@font-face {
  font-family: Gentium;
  src: local(Gentium), url(/fonts/Gentium.ttf);
}

@font-face {
  font-family: Headline;
  src: local(Futura-Medium), 
       url(fonts.svg#MyGeometricModern) format("svg");
}

@font-face {
  font-family: Japanese;
  src: local(HiraKakuPro-W3), local(Meiryo), local(IPAPGothic);
}

@font-face {
  font-family: Hoefler Text Ornaments;
  /* has the same font properties as Hoefler Text Regular */
  src: local(HoeflerText-Ornaments); 
}

4.4 Font property descriptors: the ‘font-style’, ‘font-weight’, ‘font-stretch’ descriptors

These descriptors define the characteristics of a font face and are used in the process of matching styles to specific faces. For a font family defined with several @font-face rules, user agents can either download all faces in the family or use these descriptors to selectively download font faces that match actual styles used in document. The values for these descriptors are the same as those for the corresponding font properties except that relative keywords are not allowed: bolder, lighter, wider, narrower. If these descriptors are omitted, default values are assumed.

The value for these font face style attributes is used in place of the style implied by the underlying font data. This allows authors to combine faces in flexible combinations, even in situations where the original font data was arranged differently. User agents that implement synthetic bolding and obliqueing should only apply synthetic styling in cases where the font descriptors imply this is needed, rather than based on the style attributes implied by the font data.

4.5 Character range: the ‘unicode-range’ descriptor

This descriptor defines the range of Unicode characters supported by a given font. The values of <urange> are expressed using hexadecimal numbers prefixed by "U+", corresponding to Unicode character code points. The unicode-range descriptor serves as a hint for user agents when deciding whether or not to download a font resource.

Unicode range values are written using hexadecimal values and are case insensitive. Each is prefixed by "U+" and multiple, discontinuous ranges are separated by commas. Whitespace before or after commas is ignored. Valid character code values vary between 0 and 10FFFF inclusive. A single range has three basic forms:

• a single code point (e.g. U+416)
• an interval value range (e.g. U+400-4ff)
• a range where trailing ‘?’ characters imply ‘any digit value’ (e.g. U+4??)

Ranges that do not fit any of the above three forms are considered to be parse errors and the descriptor is omitted. Interval ranges consisting of a single code point are valid. Ranges specified with ‘?’ that lack an initial digit (e.g. "U+???") are also valid, and are treated as if there was a single 0 before the question marks (thus, "U+???" = "U+0???" = "U+0000-0FFF"). "U+??????" is not a syntax error, even though "U+0??????" would be. Ranges can overlap but interval ranges that descend (e.g. U+400-32f) are invalid and omitted rather than treated as parse errors; they have no effect on other ranges in a list of ranges. Ranges are clipped to the domain of Unicode code points (currently 0 - 10FFFF inclusive); a range entirely outside the domain is omitted. Without any valid ranges, the descriptor is omitted. User agents may normalize the list of ranges into a list that is different but represents the equivalent set of character code points.

The character range can be a subset of the full character map of the underlying font. The effective unicode-range used when mapping characters to fonts is the intersection of the unicode range specified and the underlying character map of the font. This means that authors do not need to define the unicode-range of a font precisely, broad ranges for which a sparse set of code points are defined in the font can be used. Code points outside of the defined unicode-range are ignored, irregardless of whether the font contains a glyph for that code point or not. User agents that download fonts for characters outside the defined unicode-range are considered non-conformant. Likewise, user agents that render a character using a font resource for which the defined unicode-range does not include that character are also considered non-conformant.

Example ranges for specific languages or characters:

unicode-range: U+A5;

a single code point, the yen/yuan symbol

unicode-range: U+0-7F;

code range for basic ASCII characters

unicode-range: U+590-5ff;

code range for Hebrew characters

unicode-range: U+A5, U+4E00-9FFF, U+30??, U+FF00-FF9F;

code range for Japanese kanji, hiragana and katakana characters plus yen/yuan symbol

@font-face {
  font-family: BBCBengali;
  src: url(fonts/BBCBengali.ttf) format("opentype");
  unicode-range: U+00-FF, U+980-9FF;
}

@font-face {
  font-family: STIXGeneral;
  src: local(STIXGeneral), url(/stixfonts/STIXGeneral.otf);
  unicode-range: U+000-49F, U+2000-27FF, U+2900-2BFF, U+1D400-1D7FF;
}

Multiple @font-face rules with different unicode ranges for the same family and style descriptor values can be used to create composite fonts that mix the glyphs from different fonts for different scripts. This can be used to combine fonts that only contain glyphs for a single script (e.g. Latin, Greek, Cyrillic) or it can be used by authors as a way of segmenting a font into fonts for commonly used characters and less frequently used characters. Since the user agent will only pull down the fonts it needs this helps reduce page bandwidth.

If the unicode ranges overlap for a set of @font-face rules with the same family and style descriptor values, the rules are ordered in the reverse order they were defined; the last rule defined is the first to be checked for a given character.

@font-face {
  font-family: JapaneseWithGentium;
  src: local(MSMincho);
  /* no range specified, defaults to entire range */
}

@font-face {
  font-family: JapaneseWithGentium;
  src: url(../fonts/Gentium.ttf);
  unicode-range: U+0-2FF;
}

/* fallback font - size: 4.5MB */
@font-face {
  font-family: DroidSans;
  src: url(DroidSansFallback.ttf);
  /* no range specified, defaults to entire range */
}

/* Japanese glyphs - size: 1.2MB */
@font-face {
  font-family: DroidSans;
  src: url(DroidSansJapanese.ttf);
  unicode-range: U+3000-9FFF, U+ff??;
}

/* Latin, Greek, Cyrillic along with some 
   punctuation and symbols - size: 190KB */
@font-face {
  font-family: DroidSans;
  src: url(DroidSans.ttf);
  unicode-range: U+000-5FF, U+1e00-1fff, U+2000-2300;
}

body { font-family: DroidSans; }

<p>This is that</p>

<p>This &#x21e8; that<p>

5 Font matching algorithm

The procedure for choosing fonts consists of iterating over the font families determined by the font-family property, selecting a font face with the appropriate style based on other font properties and then determining whether a glyph exists for a given character. This procedure is performed on each character to be rendered. Optimizations are allowed provided that an implementation behaves as if the algorithm had been followed exactly. Matching occurs in a well-defined order to insure that the results are as consistent as possible across user agents, given an identical set of available fonts and rendering technology.

To begin with, a user agent must determine the set of font families available on a given platform and determine the style characteristics of all faces for each family. If two faces have the exact same style characteristics, one of them is ignored. Fonts available via @font-face rules are referenced per document and are not treated as generally available fonts.

1. For each character within a given element, the user agent evaluates the font properties applicable. The user agent starts with the first family name in the ‘font-family’ prioritized list.
2. If the family name is a generic family name, the user agent looks up the appropriate font family name to be used. User agents may choose the generic font family to use based on the language of the containing element or the Unicode range of the character. The user agent attempts to find the family name among fonts defined via @font-face rules and then among available system fonts.
3. If a font family match occurs, the user agent then attempts to select a face that matches the remaining font properties. It matches these properties in the order given below:
   1. ‘font-stretch’ is tried first. ‘normal’ matches a font not labeled as ‘condensed’ or ‘expanded’.
   2. ‘font-style’ is tried next. ‘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.
   3. ‘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.
   4. ‘font-weight’ is matched next, it will never fail. If bolder/lighter relative weights are used, calculate the effective weight based on the inherited weight value, as described in the definition of font-weight above. Given the desired weight and the set of face weights that match the properties above, if the desired weight is available that face matches. Otherwise, a weight is chosen using the rules below:
      • If the desired weight is less than 400, weights below the desired weight are checked in descending order followed by weights above the desired weight in ascending order until a match is found.
      • If the desired weight is greater than 500, weights above the desired weight are checked in ascending order followed by weights below the desired weight in descending order until a match is found.
      • If the desired weight is 400, 500 is checked first and then the rule for desired weights less than 400 is used.
      • If the desired weight is 500, 400 is checked first and then the rule for desired weights less than 400 is used.
   5. ‘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.
4. If no matching face exists or the matched face does not contain a glyph for the character to be rendered, the next family name is selected and the previous two steps repeated. If the matched font is defined via an @font-face rule, the font resource is downloaded. Otherwise if the matched font is defined via @font-face and needs to be downloaded, the user agent can either wait until the font is downloaded or render once with substituted font metrics and render again once the font is downloaded.
5. If there are no more font families to be evaluated and no matching face has been found, then the user agent performs a system font fallback procedure to find the best match for the character to be rendered. The result of this procedure may vary across user agents.
6. If a particular character cannot be displayed using any font, the user agent should indicate by some means that a character is not being displayed, either by displaying a symbolic representation of the missing glyph or using the ‘missing character’ glyph from another font.

*:lang(ja-jp) { font: 900 14pt/16pt "Heisei Mincho W9", serif; }
*:lang(zh-tw) { font: 800 14pt/16.5pt "Li Sung", serif; }

Appendix A: Mapping font features to CSS properties

This section is included as background for some of the problems and situations that are described in other sections. It should be viewed as informative only.

Font properties in CSS are designed to be independent of the underlying font formats used; they can be used to specify bitmap fonts, Type1 fonts, SVG fonts in addition to the common TrueType and OpenType fonts. But there are facets of the TrueType and OpenType formats that often cause confusion for authors and present challenges to implementors on different platforms.

Originally developed at Apple, TrueType was designed as an outline font format for both screen and print. Microsoft joined Apple in developing the TrueType format and both platforms have supported TrueType fonts since then. Font data in the TrueType format consists of a set of tables distinguished with common four-letter tag names, each containing a specific type of data. For example, naming information, including copyright and license information, is stored in the ‘name’ table. The character map (‘cmap’) table contains a mapping of character encodings to glyphs. Apple later added additional tables for supporting enhanced typographic functionality; these are now called Apple Advanced Typography, or AAT, fonts. Microsoft and Adobe developed a separate set of tables for advanced typography and called their format OpenType.

In many cases the font data used under Microsoft Windows or Linux is slightly different from the data used under Apple's Mac OS X because the TrueType format allowed for variation across platforms. This includes font metrics, names and character map data.

Font family names for TrueType and OpenType fonts are contained in the ‘name’ table, in name records with name ID 1. Mulitple names can be stored for different locales but Microsoft recommends fonts always include at least a US English version of the name. On Windows, the family name can only be used for a maximum of four faces; for larger groupings the "preferred family" (name ID 16) or "WWS family" (name ID 21) can be used. The full font name (name ID 4) and the Postscript name (name ID 6) describe a single face uniquely. The bold face of the Gill Sans family has a fullname of "Gill Sans Bold" and a Postscript name of "GillSans-Bold". There can be multiple localized versions of the fullname for a given face but the Postscript name is always a unique name made from a limited set of ASCII characters.

On various platforms, different names are used to search for a font. For example, with the Windows GDI CreateIndirectFont API, either a family or fullname can be used to lookup a face while on Mac OS X the ATSFontFindFromName and ATSFontFindFromPostScriptName API calls are used to lookup a given face using the fullname and Postscript name. Under Linux, the fontconfig API allows fonts to be searched using any of these names. In situations where platform API's automatically substitute other font choices, it may be necessary to verify a returned font matches a given name.

The weight of a given face can be determined via the usWeightClass field of the OS/2 table or inferred from the style name (name ID 2). Likewise, the width can be determined via the usWidthClass of the OS/2 table or inferred from the style name. For historical reasons, font designers have sometimes skewed values in the OS/2 table to work around problems in the Windows GDI API.

Rendering complex scripts that use contextual shaping such as Thai, Arabic and Devanagari requires features present only in OpenType or AAT fonts. Currently, complex script rendering is supported on Windows and Linux using OpenType font features while AAT font features are used under Mac OS X. Apple has indicated it intends support complex script rendering using OpenType font features in the future.

Appendix B: Font licensing issues

The use of fonts on the web is often surrounded in controversy. Font designers expend huge amounts of effort to create their designs, painstakingly refining letterforms and tuning font data to assure that the letterforms appear as desired both in print and on the screen. As a result they often license their fonts very carefully, often with somewhat complex terms. Authors who want to use specific fonts via a downloadable font mechanism must always carefully verify that their intended use is within the scope of the font license. Many commercial fonts presently do not allow web downloading of their fonts in any form. Font formats often store references to the font license within the font data itself. When in doubt, it's best to verify with the font designer directly. Vendors that bundle fonts with their products are also strongly encouraged to carefully explain the license details that covers the fonts they bundle.

Acknowledgments

A special thanks to Robert Bringhurst for the sublime mind expansion that is The Elements of Typographic Style.

References

Normative

[UNICODE5]

The Unicode Consortium. The Unicode Standard, Version 5.1.0. Addison-Wesley. 2007. ISBN 0-321-48091-0. URL: http://www.unicode.org/versions/Unicode5.1.0/

Informative

[ARABIC-TYPO]

Huda Smitshuijzen AbiFares. Arabic Typography: A Comprehensive Sourcebook. Saqi Books. 2001. ISBN 0-86356-347-3.

[ELEMTYPO]

Robert Bringhurst. The Elements of Typographic Style, Version 3.1. Hartley & Marks. 2005. ISBN 0-88179-206-3.

[LANGCULTTYPE]

John D. Berry, Ed. Language Culture Type. Graphis. 2001. ISBN 1-932026-01-0.

Index

• <absolute-size>
  • definition of, 3.6
• aspect value, 3.7
• at-rules, 4.1
• bicameral
  • definition of, 3.5
• cursive, definition of, #
• fantasy, definition of, #
• font, 3.8
• <font-description>
  • definition of, 4.1
• @font-face, 4.1, 4.1, 4.3
• <font-face-name>
  • definition of, 4.3
• font-family, 3.1, 4.2
• font-size, 3.6
• font-size-adjust, 3.7
• font-stretch, 3.3, 4.4
• font-style, 3.4, 4.4
• font-variant, 3.5
• font-weight, 3.2, 4.4
• <length>, 3.6
• monospace, definition of, #
• <number>, 3.7
• <percentage>, 3.6
• <relative-size>
  • definition of, 3.6
• sans-serif, definition of, #
• serif, definition of, #
• src, 4.3
• system fonts, 3.8
• unicameral
  • definition of, 3.5
• unicode-range, 4.5
• <urange>
  • definition of, 4.5

Property index