CSS Fonts Module Level 4

1. Introduction

This specification includes and expands on the basic font features described in the CSS3 Fonts specification ([CSS-FONTS-3]).

1.1. Value Definitions

This specification follows the CSS property definition conventions from [CSS2] using the value definition syntax from [CSS-VALUES-3]. Value types not defined in this specification are defined in CSS Values & Units [CSS-VALUES-3]. Combination with other CSS modules may expand the definitions of these value types.

In addition to the property-specific values listed in their definitions, all properties defined in this specification also accept the CSS-wide keywords as their property value. For readability they have not been repeated explicitly.

1.2. Interaction With Font-Relative Units

The following properties defined in this specification are font-affecting properties:

• All longhands of the font shorthand

• All longhands of the font-synthesis shorthand

• All longhands of the font-variant shorthand

• font-language-override

• font-feature-settings

• font-variation-settings

• font-optical-sizing

2. Basic 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 independently of each other.

2.1. Font family: the font-family property

This property specifies a prioritized list of font family names or generic family names. A font family defines a set of faces that vary in weight, width or slope. CSS uses the combination of a family name with other font properties to select an individual face. Using this selection mechanism, rather than selecting a face via the style name as is often done in design applications, allows some degree of regularity in textual display when fallback occurs.

Component values are a comma-separated list indicating alternatives. 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. (See § 5.3 Cluster matching.) This allows for differences in available fonts across platforms and for differences in the range of characters supported by individual fonts.

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

There are three types of font family names, two of which may be used with this property:

<font-family-name>

The name of a font family, such as Helvetica or Verdana in the previous example.

This might be a locally-instaled font, or might be a web font.

<generic-font-family>

Each <generic-font-family> keyword represents a generic font choice, and behaves as a potential alias for one or more locally-installed fonts belonging to the specified generic font category. A <generic-font-family> can thus be used as a fallback for when an author’s more specific font choices are not available.

There are three types of generic family:

1. Generics which apply to all Unicode characters and will always match a locally installed font. For example, monospace.

2. Generics which apply to all Unicode characters but may not match to a locally installed font on some systems. For example, ui-rounded.

3. Generics which are writing-system specific, only apply to a subset of Unicode characters, and may not match to a locally installed font on some systems. For example, generic(fangsong).

Authors are encouraged to append a generic font family as a last alternative for improved robustness, and to use a more specific generic font family, if applicable, to prefer a specific style even if the individual named font family is not available.

Note that <generic-font-family> keywords cannot be quoted (otherwise they are interpreted as a <font-family-name>).

The set of generic family keywords is defined in § 2.1.5 Generic font families.

<system-font-family-name>

A locally installed system font, whose use is subject to certain constraints. In particular, it may not be used with the font-family property, but can be used with the font shorthand.

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.

Tests

• system-fonts-serialization.tentative.html (live test) (source)

2.1.1. Syntax of <font-family-name>

<font-family-name> = <string> | <custom-ident>+

Font family names other than generic families or system font families must either be given quoted as <string>s, or unquoted as a sequence of one or more <custom-ident>.

Note: This means most punctuation characters and digits at the start of each token must be escaped in unquoted font family names.

font-family: Red/Black, sans-serif;
font-family: "Lucida" Grande, sans-serif;
font-family: Ahem!, sans-serif;
font-family: test@foo, sans-serif;
font-family: #POUND, sans-serif;
font-family: Hawaii 5-0, sans-serif;

Any identifier which could be misinterpreted as a pre-defined keyword in the font-family value definition, or the CSS-wide keywords, is not allowed.

Note: this means that if you really have a font whose name is the same as one of the <generic-font-family> names, or the system font names, or the CSS-wide keywords, it must be quoted.

font-family: "sans-serif", sans-serif;
font-family: "default", sans-serif;
font-family: "initial", sans-serif;
font-family: "inherit", sans-serif;

If a sequence of identifiers is given as a <font-family-name>, the computed value is the name converted to a string by joining all the identifiers in the sequence by single spaces.

To avoid mistakes in escaping, it is recommended to quote font family names that contain white space, digits, or punctuation characters other than hyphens:

body { font-family: "New Century Schoolbook", serif }

<body style="font-family: '21st Century', fantasy">

Font family names that happen to be the same as a font-family keyword value (e.g. CSS-wide keywords such as inherit, or <generic-font-family> keywords such as serif) must be quoted to prevent confusion with the keywords of the same names. UAs must not consider these keywords as matching the <font-family-name> type.

2.1.2. Syntax of <generic-font-family>

<generic-font-family> = <generic-font-script-specific>| <generic-font-complete> | <generic-font-incomplete>
<generic-font-script-specific> = generic(fangsong) | generic(kai) | generic(khmer-mul) |  generic(nastaliq)
<generic-font-complete> = serif | sans-serif | system-ui | cursive | fantasy | math | monospace
<generic-font-incomplete> = ui-serif | ui-sans-serif | ui-monospace | ui-rounded

To make the syntax less succeptible to clashes, more recently defined generic font families are identified using a functional syntax.

body { font-family: "Adobe Fangsong Std R", generic(fangsong), serif}

2.1.3. Syntax of <system-font-family-name>

<system-font-family-name> = caption | icon | menu | message-box | small-caption | status-bar

2.1.4. Relationship Between Faces and Families

A font family name only specifies a name given to a set of font faces; it does not specify an individual face.

For example, given the availability of the fonts below, Futura would match but Futura Medium would not:

Note: The CSS definition of font attributes used for selection are explicitly not intended to define a font taxonomy. A type designer’s idea of a family can often extend to a set of faces that vary along axes other than just the standard axes of weight (font-weight), width (font-width), and slant (font-style). A family can vary along axes that are unique to that family. The CSS font selection mechanism merely provides a way to determine the “closest” match when substitution is necessary.

Note: The precise way a set of fonts are grouped into font families varies depending upon the platform font management APIs. For example, the Windows GDI API only allows four faces to be grouped into a family, while the DirectWrite API, Core Text API, and other platforms support font families with a variety of weights, widths, and slopes (see Appendix A: Mapping platform font properties to CSS properties for more details).

See § 5.1 Localized name matching below for information on how font-family names are matched.

2.1.5. Generic font families

A generic font family is a font family which has a standard name (as defined by CSS), but which is an alias for an existing installed font family present on the system. However, a single generic font family may be a composite face combining different typefaces based on such things as the Unicode range of the character, the content language of the containing element, user preferences, system settings, etc. Different generic font families may map to the same used font.

Note: Generic font families are intended to be widely implemented on many platforms, unlike arbitrary <font-family-name>s which are usually platform-specific names. They are expected to map to different fonts on different platforms. Authors may specify these generic family names if they desire their text to follow a particular design on many platforms, and are not particular about which specific font is chosen on those platforms.

User agents should provide reasonable default choices for the generic font families, that 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 faces for the generic font families.

serif

Serif fonts represent glyphs that 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.

Note: serif and sans-serif only apply to a small handful of writing scripts. Their use as generic font families in CSS is historical, and reflects the Latin-centric nature of early Web development. Better and more widely applicable names would have been, for example, "modulated" and "monoline". However, for reasons of Web compatibility, these names cannot be changed.

CSS uses the term "serif" to apply to a font for any script, although other names might be more familiar for particular scripts, such as Mincho (Japanese), Sung or Song (Chinese), Batang (Korean). For Arabic, the Naskh style would correspond to serif.

serif must always map to at least one matched font face.

Note: No guarantee is placed on the character coverage of that font face. Therefore, the font serif is mapped to may not end up being used for all content.

sans-serif

Glyphs in sans-serif fonts, as the term is used in CSS, are generally low contrast (vertical and horizontal stems have the close to the same thickness) and 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 might be more familiar for particular scripts, such as Gothic (Japanese), Hei (Chinese), or Gulim (Korean).

sans-serif must always map to at least one matched font face.

Note: No guarantee is placed on the character coverage of that font face. Therefore, the font sans-serif is mapped to may not end up being used for all content.

cursive

Glyphs in cursive fonts generally use a script style, and the result looks more like handwritten pen or brush writing than printed letterwork. 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.

fantasy

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

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.

monospace must always map to at least one matched font face.

Note: No guarantee is placed on the character coverage of that font face. Therefore, the font monospace is mapped to may not end up being used for all content.

system-ui

This generic font family lets text render with the default user interface font (which, as with all § 2.1.5 Generic font families, may be a composite font) on the platform on which the UA is running. A cross-platform UA should use different fonts on its different supported platforms. The purpose of system-ui is to allow web content to integrate with the look and feel of the native OS. This is useful for hybrid, web or cross-platform applications.

Tests

• system-ui-ar.html (live test) (source)
• system-ui-ja-vs-zh.html (live test) (source)
• system-ui-ja.html (live test) (source)
• system-ui-mixed.html (live test) (source)
• system-ui-ur-vs-ar.html (live test) (source)
• system-ui-ur.html (live test) (source)
• system-ui-zh.html (live test) (source)
• system-ui.html (live test) (source)

The precise font(s) used will depend on factors such as platform support, platform language, locale settings, user preferences, Unicode coverage and the content language. UA may optionally choose to use the text rendering engine provided by the platform when using system-ui to match the appearance of the default user interface more closely.

As with other generic font families, the substitution of specific installed fonts for system-ui does not affect the computed style.

<div id="system-text" style="font-family: system-ui"></div>
...
window.getComputedStyle(document.getElementById("system-text")).getPropertyValue("font-family");

The script above should not have any knowledge of how system-ui is expanded to include a collection of system user interface fonts. In particular, the above script should yield a result of "system-ui" on every platform.

Note: system-ui is highly dependent on the platform environment as multiple factors may affect the default user interface font, and may have verying level of text rendering support. This may cause the displayed typeface to be undesirable for some end users (e.g. Simplified Chinese users might get a monospaced serif font on older version of Windows; lang attribute might not affect displayed font in cases like lang="uk" in Russian locale or lang="ja" in Chinese locale). Some operating system vendors does not offer means to customise system-ui, unlike UAs that generally allow users to customise the generic sans-serif or serif font family. As the name implies, system-ui is intended for use with UI elements in web application, and not for large paragraphs of text or articles.

math

This font family is intended for use with mathematical expressions.

Such fonts may include additional data (for example, the OpenType MATH table) to help with the hierarchical process of equation layout. In particular, they may contain stylistic and stretching glyph variants useful in setting mathematical equations.

generic(fangsong)

This font family is used for Fang Song (仿宋) typefaces in Chinese. Fang Song is a relaxed, intermediate form between Song (serif) and Kai (generic(kai)). Typically, the horizontal lines are tilted, the endpoint flourishes are smaller, and there is less variation in stroke width, compared to a Song style. Fang Song is often used for official Chinese Government documents.

Note: generic(fangsong) might not map to any locally installed font, but if it does, that font will be in Fang Song style.

generic(kai)

This font family is used in Simplified & Traditional Chinese. A major typeface, which provides calligraphic styles for Chinese text. It shows notable handwriting features. Kai is commonly used in official documents and textbooks. Most official documents in Taiwan use Kai in full text. Kai can also be combined with other typefaces to be used in text that needs to be differentiated from the rest of the content, for example, headlines, references, quotations, and dialogs.

Note: generic(kai) might not map to any locally installed font, but if it does, that font will be in Kai style.

generic(khmer-mul)

This font family is used in the Khmer language (used in Cambodia), for titles and headings, or to emphasise important names or nouns. Compared to the upright (âksâr chôr) style, which is used for regular text, âksâr mul is characterized by heavier, more rounded letter shapes, and may include more ligated forms.

Despite the visually heavier style, the font weight for regular text in generic(khmer-mul) is unchanged (400).

Note: generic(khmer-mul) might not map to any locally installed font, but if it does, that font will be in âksâr mul style.

generic(nastaliq)

This font family is the standard way of writing Urdu and Kashmiri, and is also often a preferred style for Persian and other language text, especially in literary genres such as poetry. Key features include a sloping baseline for joined letters, and overall complex shaping and positioning for base letters and diacritics alike. There are also distinctive shapes for many glyphs and ligatures. It is important not to fall back to a naskh style for languages such as Urdu and Kashmiri.

Note: generic(nastaliq) might not map to any locally installed font, but if it does, that font will be in Nastaliq style.

ui-serif

This font family is used for the serif variant of the system’s user interface. The purpose of ui-serif is to allow web content to integrate with the look and feel of the native OS.

Note: ui-serif is not expected to map to any font on platforms without an appropriate system font.

Note: see notes on system-ui for potential issues.

ui-sans-serif

This font family is used for the sans-serif variant of the system’s user interface. The purpose of ui-sans-serif is to allow web content to integrate with the look and feel of the native OS.

Note: ui-sans-serif is not expected to map to any font on platforms without an appropriate system font.

Note: see notes on system-ui for potential issues.

ui-monospace

This font family is used for the monospaced variant of the system’s user interface. The purpose of ui-monospace is to allow web content to integrate with the look and feel of the native OS.

Note: ui-monospace is not expected to map to any font on platforms without an appropriate system font.

Note: see notes on system-ui for potential issues.

ui-rounded

This font family is used for the rounded variant of the system’s user interface. The purpose of ui-rounded is to allow web content to integrate with the look and feel of the native OS.

Note: ui-rounded is not expected to map to any font on platforms without an appropriate system font.

Note: see notes on system-ui for potential issues.

2.2. Font weight: the font-weight property

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

This property accepts values of the following:

<font-weight-absolute> = [ normal | bold | <number [1,1000]> ]

Values have the following meanings:

<number [1,1000]>

Each number indicates a weight that is at least as dark as its predecessor. Only values greater than or equal to 1, and less than or equal to 1000, are valid, and all other values are invalid. Numeric values typically 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)

Note: A font might internally provide its own weight name mappings, but those mappings within the font are disregarded in CSS.

normal

Same as 400.

bold

Same as 700.

bolder

Specifies a bolder weight than the inherited value. See § 2.2.1 Relative Weights.

lighter

Specifies a lighter weight than the inherited value. See § 2.2.1 Relative Weights.

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. Alternately, weights may be inferred from style names that correspond roughly with the scale above. The scale is relative, so a face with a larger weight value must never appear lighter. If style names are used to infer weights, care should be taken to handle variations in style names across locales.

2.2.1. Relative Weights

Specified values of bolder and lighter indicate weights relative to the weight of the parent element. The computed weight is calculated based on the inherited font-weight value using the chart below.

Note: 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 can use numerical values instead of relative weights.

2.2.2. Missing weights

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 § 5 Font Matching Algorithm for a precise definition.)

The examples here illustrate which face is used for different weights. Grey indicates that a face for the desired weight does not exist, so a face with a nearby weight is used.

Most user agents model a font as having a particular weight which often corresponds to one of the numbers in the nine-step scale described above. While this is true of most fonts, some fonts might be configurable so as to support a range of weights. In this situation, the user agent uses a face with a weight as close as possible to the weight requested (see § 5 Font Matching Algorithm for the precise algorithm). In particular, a user agent using a font which supports a range of weights should behave the same as if a font is present at each individual weight in the range. For TrueType / OpenType fonts that use variations, the wght variation is used to implement varying weights. Fractional weights are valid.

Although the practice is not well-loved by typographers, bold faces are often synthesized by user agents for families that lack actual bold faces. For the purposes of font matching, these faces must be treated as if they exist within the family. Authors can explicitly avoid this behavior by using the font-synthesis property.

2.3. Font width: the font-width property

The font-width property selects a normal, condensed, or expanded face from a font family. Values are specified either as percentages or as keywords which map to a percentage as defined in the following table:

<percentage [0,∞]> values represent the fractional width of the glyphs, with 100% representing “normal” glyph widths (as defined by the font designer). Values less than 0% are invalid.

When a face does not exist for a given width, values less than 100% map to a narrower face if one exists, otherwise a wider face. Conversely, values greater than or equal to 100% map to a wider face if one exists, otherwise a narrower face. Some fonts might support a range of width values; if the requested width value is not available in the font, the closest supported value is used, using the same mapping rules (see the § 5 Font Matching Algorithm for the precise algorithm). For TrueType / OpenType fonts that support variations, the wdth variation is used to implement varying widths.

The figure below shows how nine font-width property settings affect font matching for a font family containing a variety of discrete widths. Grey indicates a width for which no face exists and a different width is substituted:

getComputedStyle() always serializes its value as a <percentage>, regardless of how the value was specified by the author, or whether or not a keyword happens to map to the value.

2.3.1. Font width: the font-stretch legacy name alias

For historical reasons, a font-stretch property exists which is a legacy name alias and functions in the identical way to the font-width.

h1 {font-stretch: condensed; }

h1 {font-width: condensed; }

User agents must not synthesize condensed or expanded faces for font families which lack such faces and which do not have a width variation axis. In particular, user agents must not geometrically stretch such faces.

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

Compare the artificially sloped renderings of Palatino "a" and Baskerville "N" in grey with the actual italic versions:

Values have the following meanings:

normal

Matches against a face that is classified as a normal face, one that is neither italic or obliqued. This represents an oblique value of "0".

italic

Matches against a font that is labeled as an italic face, or an oblique face if one does not exist. The angle and direction of slant is unspecified.

left

Matches against a font that is labeled as an italic face, with a positive (clockwise) slant; or an oblique face with positive slant, if one does not exist.

right

Matches against a font that is labeled as an italic face, with a negative (counter-clockwise) slant; or an oblique face with negative slant, if one does not exist.

oblique <angle [-90deg,90deg]>?

Controls matching against an oblique face. Positive angles represent a clockwise slant; negative angles represent a counter-clockwise slant. The lack of an <angle> represents 14deg. (Note that a font might internally provide its own mapping for "oblique", but the mapping within the font is disregarded.) Fractional and negative values are accepted; however, values less than -90deg or values greater than 90deg are invalid. If no oblique faces exist, and font-synthesis-style has the value auto, a synthetic oblique face will be generated.

A font family might contain no italic or oblique faces, only an italic face and no oblique, only an oblique face and no italic, both an oblique and an italic, multiple oblique faces at various angles, or various combinations thereof. The font matching routine will select a font to use which is of the correct sign as the requested angle, and (if there are multiple such faces) closest to the requested angle. In general, for a requested angle greater or equal to 11deg, larger angles are preferred; otherwise, smaller angles are preferred. (See § 5 Font Matching Algorithm.) For TrueType / OpenType fonts that use variations, the slnt variation is used to implement oblique values, and the ital variation with a value of 1 is used to implement the italic values.

Note: the OpenType slnt axis is defined with a positive angle meaning a counter-clockwise slant, the opposite direction to CSS. The CSS implementation will take this into account when using variations to produce oblique faces.

What direction should positive and negative obliques skew in vertical writing mode? How do we achieve skews in the opposite dimension (needed for vertical writing)?

If no italic or oblique face is available, oblique faces may be synthesized by rendering non-obliqued faces with an artificial obliquing operation. The use of these artificially obliqued faces can be disabled using the font-synthesis property.

Note: While oblique faces can be simulated by artificially sloping the glyphs of the regular face, this is not equivalent to a true oblique, in which optical stroke thicknesses are properly preserved despite the slant. It is always better to use an actual oblique font rather than rely on a synthetic version.

For the purposes of font matching, User agents may treat italic as a synonym for oblique. For user agents that treat these values distinctly, synthesis must not be performed for italic.

Note: Authors should also be aware that synthesized approaches might not be suitable for scripts like Cyrillic, where italic forms are very different in shape. It is always better to use an actual italic font rather than rely on a synthetic version.

Note: 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 when implementing synthesis across fonts, as italic faces in a family can have different character maps than Roman faces.

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

Note: There is no requirement on how closely a glyph should fit its EM box. Individual fonts can have a different apparent visual size when rendered at the same font-size. Additionally, glyphs might render arbitrarily far outside their EM box; and if they overflow their containing block can induce ink overflow.

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. See § 2.5.1 Absolute Size Keyword Mapping Table.

Possible values are:

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

<relative-size>

A <relative-size> keyword is interpreted relative to the computed font-size of the parent element and possibly the table of font sizes. Possible values are:

[ larger | smaller ]

If the parent element has a keyword font size in the absolute size keyword mapping table, larger may compute the font size to the next entry in the table, and smaller may compute the font size to the previous entry in the table. For example, if the parent element has a font size of font-size:medium, specifying a value of larger may make the font size of the child element font-size:large.

Instead of using next and previous items in the previous keyword table, User agents may instead use a simple ratio to increase or decrease the font size relative to the parent element. The specific ratio is unspecified, but should be around 1.2–1.5. This ratio may vary across different elements.

Note: A sight-impaired user may request a user agent use a higher ratio than default, in order to aid readability. In addition, a user agent may choose to use different ratios when it detects paragraph text as opposed to title text.

<length-percentage [0,∞]>

A length value specifies an absolute font size (independent of the user agent’s font table). Negative lengths are invalid.

A percentage value specifies an absolute font size relative to the parent element’s computed font-size. Negative percentages are invalid.

Note: Use of percentage values or font-relative lengths such as ems and rems leads to more robust and cascadable style sheets.

math

Special mathematical scaling rules must be applied when determining the computed value of the font-size property.

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

Note: The used value of this property can differ from its computed value due to font-size-adjust. However, child elements inherit the computed font-size value, which is not affected by font-size-adjust (otherwise, the effect of font-size-adjust would compound).

The actual value of this property can differ from the used value due to the unavailability of certain font sizes.

font-size: clamp(10px, ..., 36px);

2.5.1. Absolute Size Keyword Mapping Table

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.

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

To preserve readability, an UA applying these guidelines should nevertheless avoid creating font sizes of less than 9 device pixels per EM unit.

2.6. Relative sizing: the font-size-adjust property

For any given font size, the apparent size and effective legibility of text varies across fonts. For bicameral 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 and is equal to the x-height of a font divided by the font size.

Note: For text which uses diacritics, too large an x-height will actually decrease legibility as the diacritics become cramped.

In situations where font fallback occurs, fallback fonts might not share the same aspect value as the desired font family and will thus be 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 regardless of the font used.

p {
  font-family: Verdana, Futura, Times;
}
p.adj {
  font-size-adjust: 0.545;
}

<p>Lorem ipsum dolor sit amet, ...</p>
<p class="adj">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 to 0.545, so that the actual font size is adjusted to preserve the x-height of Verdana across each row. Note how small text remains relatively legible across each row in the lower half.

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 [0,∞]>

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

Negative values are invalid.

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.

The value of font-size-adjust affects the used value of font-size but does not affect the computed value. It affects the size of relative units that are based on font metrics such as ex and ch but does not affect the size of em units. Since numeric values of line-height refer to the computed size of font-size, font-size-adjust does not affect the used value of line-height.

Note: In CSS, authors often specify line-height as a multiple of the font-size. Since the font-size-adjust property affects the used value of font-size, authors should take care setting the line height when font-size-adjust is used. Setting the line height too tightly can result in overlapping lines of text in this situation.

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>

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.

2.7. Shorthand font property: the font property

The syntax of this property is based on a traditional typographical shorthand notation to set multiple properties related to fonts. For historical and backwards-compatibility reasons, it is almost a shorthand property.

The font property is, except as described below, a shorthand property for setting font-style, font-variant, font-weight, font-width, font-size, line-height, font-family at the same place in the stylesheet.

Values for the font-variant property can also be included but only those supported in CSS 2.1; none of the font-variant values added in CSS Fonts Levels 3 or 4 can be used in the font shorthand:

<font-variant-css2>
    = normal | small-caps

Values for the font-width property can also be included but only those supported in CSS Fonts level 3, none of the font-width values added in this specification can be used in the font shorthand:

<font-width-css3>
    = normal | ultra-condensed | extra-condensed | condensed |
    semi-condensed | semi-expanded | expanded | extra-expanded |
    ultra-expanded

Therefore we have the following classification of font-related properties and their interaction with the font property:

Set Explicitly

These longhand properties may also be set using the font shorthand property:

• font-family
• font-size
• font-width
• font-stretch (css3)
• font-style
• font-variant-caps (css2)
• font-weight
• line-height

Reset Implicitly

These properties are a reset-only sub-property of the font property and thus may not be set, but are reset to their initial values:

• font-feature-settings
• font-kerning
• font-language-override
• font-optical-sizing
• font-size-adjust
• font-variant-alternates
• font-variant-caps (css3 and above)
• font-variant-east-asian
• font-variant-emoji
• font-variant-ligatures
• font-variant-numeric
• font-variant-position
• font-variation-settings

Cascaded Independently

These (despite the property name starting with "font-") are not shorthand properties and thus are neither set nor reset by the font property:

• font-palette
• font-synthesis-weight
• font-synthesis-style
• font-synthesis-small-caps

All subproperties of the font property in the Set Explicitly and Reset Implicitly groups are first reset to their initial values.

Then, those properties the Set Explicitly group that are given explicit values in the font shorthand are set to those values. For a definition of allowed and initial values, see the individual longhand property definitions.

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: condensed oblique 12pt "Helvetica Neue", serif; }
p { font: condensed oblique 25deg 753 12pt "Helvetica Neue", serif; }

Since the font-width property was not defined in CSS 2.1, when using font-width values within font rules, authors should include a extra version compatible with older user agents:

p {
  font: 80% sans-serif;   /* for older user agents */
  font: condensed 80% sans-serif;
}

System fonts can only be set as a whole; that is, the font family, size, weight, style, etc. are all set at the same time. These values can 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.

Note that the keywords used for the system fonts listed above are only treated as keywords when they occur in the initial position, in other positions the same string is treated as part of the font family name:

font: menu;        /* use the font settings for system menus */
font: large menu;  /* use a font family named "menu" */

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
}

2.8. Controlling synthetic faces

Synthetic font faces are a fallback strategy to provide an approximation to the requested font when a font family lacks a suitable face.

Synthesis is a fallback strategy because the end result, while perhaps better than nothing at all, does not meet the level of quality of a face designed for the purpose.

Variable fonts, where the font designer has provided one or more axes of variation do not count as font synthesis and their use is not affected by the font-synthesis property.

2.8.1. Controlling synthesized bold: The font-synthesis-weight property

This property controls whether user agents are allowed to synthesize bold font faces when a font family lacks bold faces.

auto

Synthesis of bold faces is allowed

none

Synthesis of bold faces is not allowed

2.8.2. Controlling synthesized oblique: The font-synthesis-style property

This property controls whether user agents are allowed to synthesize oblique font faces when a font family lacks oblique faces.

auto

Synthesis of oblique faces is allowed

none

Synthesis of oblique faces is not allowed

oblique-only

Synthesis of oblique faces is allowed, but they must not be used as fallback if italic is specified

In vertical text, for positive oblique angles, the glyph is skewed such that the line-over edge shifts towards the line-right side while the line-under edge shifts towards the line-left side. For negative oblique angles, the glyph is skewed such that the line-over edge shifts towards the line-left side while the line-under edge shifts towards the line-right side. Skewing is about the center of the glyph.

2.8.3. Controlling synthesized small caps: The font-synthesis-small-caps property

This property controls whether user agents are allowed to synthesize small caps font faces when a font family lacks small caps faces.

auto

Synthesis of small caps faces is allowed

none

Synthesis of small caps faces is not allowed

2.8.4. Controlling synthesized super- and subscripts: The font-synthesis-position property

This property controls whether user agents are required to synthesize superscript and subscript glyphs for font-variant-position when a font lacks them.

auto

Synthesis of superscript and subscript forms is required

none

Synthesis of superscript and subscript forms is not allowed

2.8.5. Controlling synthetic faces: the font-synthesis shorthand

This property is a shorthand for the font-synthesis-weight, font-synthesis-style, font-synthesis-small-caps, and font-synthesis-position properties. Values are mapped as following:

*:lang(ar) { font-synthesis: none; }

3. Font Rendering Controls

3.1. Introduction to Font Rendering Controls

When using downloadable Web Fonts via @font-face, the user agent needs to know what to do while the font is actively loading. Most web browsers have adopted some form of timeout:

• Chrome and Firefox have a 3 second timeout after which the text is shown with the fallback font. Eventually, a swap occurs: the text is re-rendered with the intended font once it becomes available.

• Internet Explorer has a 0 second timeout which results in immediate text rendering: if the requested font is not yet available, fallback is used, and text is rerendered later once the requested font becomes available.

While these default behaviors are reasonable, they’re unfortunately inconsistent across browsers. Worse, no single approach is sufficient to cover the range of use-cases required by modern user-experience– and performance–conscious applications.

The Font Loading API [CSS-FONT-LOADING-3] allows a developer to override some of the above behaviors, but that requires scripting, a non-trivial amount of effort, and ultimately doesn’t provide sufficient hooks to cover all reasonable cases. Additionally, the developer needs to either inline the loading script into their page or load an external library, introducing additional network latency before the fonts can be loaded and delaying text rendering.

Design/performance-conscious web developers have a good sense for the relative importance of a given Web Font for the intended user experience. This specification provides them the ability to control font timeout and rendering behavior. Specifically, it lets developers:

• Define the font display policy when text is ready to be painted: block, or paint with fallback.

• Define the font display policy once the desired font is available: rerender text with the new font, or leave it with the fallback.

• Define custom timeout values for each font.

• Define custom display and timeout policies per element.

3.2. The Font Display Timeline

At the moment the user agent first attempts to use a given downloaded font face on a page, the font face’s font download timer is started. This timer advances through three periods of time associated with the font face—​the block period, the swap period, and the failure period—​which dictate the rendering behavior of any elements using the font face:

• The first period is the font block period. During this period, if the font face is not loaded, any element attempting to use it must instead render with an invisible fallback font face. If the font face successfully loads during the block period, the font face is then used normally.

• The second period, occurring immediately after the block period, is the font swap period. During this period, if the font face is not loaded, any element attempting to use it must instead render with a fallback font face. If the font face successfully loads during the swap period, the font face is then used normally.

• The third period, occurring immediately after the swap period, is the font failure period. If the font face is not yet loaded when this period starts, it’s marked as a failed load, causing normal font fallback. Otherwise, the font face is used normally.

To render with a fallback font face for a given element, the user agent must find the first font face specified in the element’s font-family list which is already loaded, and use that for rendering text. Doing this must not trigger loads of any of the fallback fonts.

To render with an invisible fallback font face for a given element, find a font face as per "render with a fallback font face". Create an anonymous font face with the same metrics as the selected font face but with all glyphs "invisible" (containing no "ink"), and use that for rendering text. Doing this must not trigger loads of any of the fallback fonts.

fallback and optional can result in some faces in a family being used while others are required to fallback, giving a "ransom note" look. Perhaps require that all fonts in a family have the same behavior (all swapped in, or all fallback)? See also the @font-feature-values for controlling the behavior on a font family basis.

4. Font Resources

4.1. The @font-face rule

The @font-face rule allows for linking to fonts that are automatically fetched and activated when needed. This allows authors to select a font that closely matches the design goals for a given page rather than limiting the font choice to a set of fonts available on a given platform. A set of font descriptors define the location of a font resource, either locally or externally, along with 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.

Its syntax is:

@font-face {
  <declaration-list>
}

The @font-face rule accepts the descriptors defined in this specification.

Each @font-facerule 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 descriptor declaration is used and all prior declarations for that descriptor are ignored.

@font-face {
font-family: Gentium;
src: url(http://example.com/fonts/Gentium.woff);
}

p { font-family: Gentium, serif; }

A given set of @font-face rules define a set of fonts available for use within the documents that contain these rules. 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. The process of activating these fonts must not make them available to other applications or to documents that don’t directly link to the same font. User agent implementers 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 installed font fallback procedure. However, this would cause a security leak since the contents of one page would be able to affect other pages, something an attacker could use as an attack vector. These restrictions do not affect caching behavior, fonts are cached the same way other web resources are cached.

This at-rule follows the forward-compatible parsing rules of CSS. Like properties in a declaration block, declarations of any descriptors that are not supported by the user agent must be ignored. @font-face rules require a font-family and src descriptor; if either of these are missing, the @font-face rule must not be considered when performing the font matching algorithm.

In cases where user agents have limited platform resources or implement the ability to disable downloadable font resources, @font-face rules must 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