CSS Fonts Module Level 4

This document contains ideas and experiments that might or might not end up in the final version of a CSS Fonts specification. Implementors are encouraged to ask about the status of a particular feature listed here on the www-style mailing list.

1. Introduction

The CSS3 Fonts specification ([CSS-FONTS-3]) describes the basic controls CSS provides for selecting and using fonts within documents. The ideas here are additions or modifications to the properties and rules defined in CSS3 Fonts.

Please note that OpenType/TrueType variable font support is still in intial stages of specification and implementation. Please comment on any bugs in this spec at https://github.com/w3c/csswg-drafts/issues. Also, please note that this spec is incomplete and only includes some of the text from https://www.w3.org/TR/css-fonts-3/.

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 independent 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 style attributes 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.

Note: Designers should note that 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, width and slope. A family can extend to include both a set of serif faces and a set of sans-serif faces or vary along axes that are unique to that family. The CSS font selection mechanism merely provides a way to determine the “closest” substitute when substitution is necessary.

Unlike other CSS properties, 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. This allows for differences in available fonts 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. For example, given the availability of the fonts below, Futura would match but Futura Medium would not:

Consider the example below:

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

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.

<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 must not be quoted. Authors are encouraged to append a generic font family as a last alternative for improved robustness.

Font family names other than generic families must either be given quoted as strings, or unquoted as a sequence of one or more identifiers. This means most punctuation characters and digits at the start of each token must be escaped in unquoted font family names.

To illustrate this, the following declarations are invalid:

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;

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 keyword value (inherit, serif, etc.) must be quoted to prevent confusion with the keywords with the same names. UAs must not consider these keywords as matching the <family-name> type. This applies to any keyword across all of CSS.

The precise way a set of fonts are grouped into font families varies depending upon the platform font management API’s. 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 for more details).

Some font formats allow fonts to carry multiple localizations of the family name. User agents must recognize and correctly match all of these names independent of the underlying platform localization, system API used or document encoding:

The details of localized font family name matching and the corresponding issues of case sensitivity are described below in the font matching section.

2.1.1. Generic font families

Each generic font family must always result in at least one matched font face, for all CSS implementations. However, the generics may be composite faces (with different typefaces based on such things as the Unicode range of the character, the language of the containing element, user preferences and system settings, among others). They are also not guaranteed to always be different from each other.

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

Serif fonts represent the formal text style for a script. This often means but is not limited to 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. 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 more due to its typographic role rather than its actual design style. Any font that is so described may be used to represent the generic serif family.

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). Any font that is so described may be used to represent the generic sans-seriffamily.

cursive

Glyphs in cursive fonts generally use a more informal 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.

system-ui

This generic font family is intended to let text render with the default user interface 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 a native app. On platforms which have a collection of system user interface fonts (e.g. for different languages), user agents may treat system-ui as a virtual font which encompasses all the platform user interface fonts. However, if this is done, the details of the virtual font must not be visible or detectable.

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

Add system-ui fingerprinting issue to Security and Privacy Considerations section per discussion.

emoji

This font family is intended for use with emoji characters.

math

This font family is intended for use with mathematical expressions.

fangsong

This font family is used for fang song typefaces in Chinese.

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

Values have the following meanings:

<number>

These values form an ordered sequence, where 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 treated as parse errors. Certain numeric values correspond to the commonly used weight names below (Note that a font might internally provide its own mappings, but those mappings within the font are disregarded):

• 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 a bolder weight than the inherited value.

lighter

Specifies a lighter weight 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 must 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:

Most user agents model a font as having a particular weight which often corresponds to one of the numbers in the nine-step scale mentioned 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 the font matching section below 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 which 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 faces that lack actual bold faces. For the purposes of style 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.

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.

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.

Note: There is a small behavior change between [CSS-FONTS-3] and this specification with the animation of the font-size property. Previously, interpolated values of font-weight were rounded to their closest multiple of 100, and the font-matching algorithm was run on these rounded values. In this specification, the font-matching algorithm is able to accept any value, so no rounding occurs. The small behavior change is due to the discontinuous nature of the font-matching algorithm.

2.3. Font width: the font-stretch property

The font-stretch property selects a normal, condensed, or expanded face from a font family.

This property accepts values of the following:

<font-stretch-absolute> = [normal | ultra-condensed | extra-condensed | condensed | semi-condensed | semi-expanded | expanded | extra-expanded | ultra-expanded | <percentage>]

Absolute keyword values are aliased to have the following meaning (Note that a font might internally provide its own mappings, but those mappings within the font are disregarded):

Values less than 0% are not allowed and are treated as parse errors. When a face does not exist for a given width, values less than 100% map to a narrower face, otherwise a wider face. Conversely, values greater than or equal to 100% map to a wider face, otherwise a narrower face. Some fonts might support a range of stretch values; if the requested stretch value is not available in the font, the closest supported value should be used, using the same mapping rules (see the font matching section below for the precise algorithm). For TrueType / OpenType fonts which use variations, the "wdth" variation is used to implement varying widths. The figure below shows how nine font-stretch property settings affect font matching for font family containing a variety of discrete widths. Grey indicates a width for which no face exists and a different width is substituted:

User Agents must not sythesize stretched faces for font families which lack actual stretched 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. 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:

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

oblique <angle>?

Controls matching against an oblique face. The lack of a number represents an angle of "20deg". Values less than -90deg or values greater than 90deg are invalid and are treated as parse errors. (Note that a font might internally provide its own mapping for "oblique", but that mapping within the font is disregarded). Matches against a font that is labeled as an oblique face, or an italic face if one is not.

Some font families might contain only zero or one italic or oblique face, while yet other families might contain multiple oblique faces with varying angles. The font matching routine will select a font to use which is closest to the requested angle. In general, for a requested angle greater or equal to 20deg, larger angles are prefered; otherwise, smaller angles are preferred (see the font matching section below for the precise algorithm). Fractional and negative values are accepted, but values less than -90 as well as values greater than 90 are not allowed and are treated as parse errors. For TrueType / OpenType fonts which 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. The meaning of a negative value for "oblique" is to slope the text in the opposite direction.

If no italic or oblique face is available, oblique faces can 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. The details of the obliquing operation are not explicitly defined.

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

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.

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 support for installed font fallback.

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. (Note that certain glyphs might 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 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 previous table, larger may make the font size equal to the next entry in the table, and smaller may make the font size of the current element equal to the previous entry in the table.

For example, if the parent element has a font size of medium, a value of larger may make the font size of the current element be 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-impared 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>

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 font size. Use of percentage values, or values in ems, leads to more robust and cascadable style sheets. Negative percentages are invalid.

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: To preserve readability, an UA applying these guidelines should nevertheless avoid creating font-size resulting in less than 9 device pixels per EM unit on a computer display.

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.

The actual value of this property might differ from the computed value due a numerical value on font-size-adjust and the unavailability of certain font sizes.

The computed value of this property is affected by the computed value of font-min-size and font-max-size.

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 }

2.6. Minimum and maximum font size: the font-min-size and font-max-size properties

These two properties allow a website or user to require an element’s font size to be clamped within the range supplied with these two properties. If the computed value font-size is outside the bounds created by font-min-size and font-max-size, the use value of font-size is clamped to the values specified in these two properties.

Some user agents provide a nonstandard mapping between the computed value of font-size and the used value of font-size. The interaction of those nonstandard algorithms with font-min-size or font-max-size is explicitly undefined.

If the font-min-size property is computed to be larger than the font-max-size property, then the font-max-size property is not used for the purposes of text rendering or rasterization. However, the computed value of font-max-size is not affected.

Users with accessibility preferences can set this in a user style sheet to force websites' text to become larger or smaller.

The computed value of these two properties affects the computed value of font-size.

2.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 might not share the same aspect value 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 regardless 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 preserve the x-height 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>

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 of the first available font 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.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-stretch, 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 this specification can be used in the font shorthand:

<font-variant-css21> = [normal | small-caps]

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

<font-stretch-css3> = [normal | ultra-condensed | extra-condensed | condensed | semi-condensed | semi-expanded | expanded | extra-expanded | ultra-expanded]

The syntax of this property is based on a traditional typographical shorthand notation to set multiple properties related to fonts.

All subproperties of the font property are first reset to their initial values, including those listed above plus font-size-adjust, font-kerning, all subproperties of font-variant, font-feature-settings, font-language-override, font-min-size, font-max-size, font-optical-sizing, font-variation-settings, and font-palette. 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-size-adjust to anything other than its initial value using the font shorthand property; instead, use the individual property.

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-stretch property was not defined in CSS 2.1, when using font-stretch 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;
}

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 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.9. Controlling synthetic faces: the font-synthesis property

This property controls whether user agents are allowed to synthesize bold or oblique font faces when a font family lacks bold or italic faces. If weight is not specified, user agents must not synthesize bold faces. If style is not specified, user agents must not synthesize italic faces. If small-caps is not specified, user agents must not synthesize small-caps faces nor all-small-caps faces. A value of none disallows all synthetic faces.

*: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, occuring 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, occuring 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 system 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

This descriptor defines the font family name that will be used in all CSS font family name matching. It is required for the @font-face rule to be valid. It overrides the 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. Likewise, platform substitutions for a given font family name must not be used.

4.3. Font reference: the src descriptor

This descriptor specifies the resource containing font data. It is required for the @font-face rule to be valid. Its 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. Activation of a font involves downloading the file or reading it from disk, parsing it, and perhaps additional user-agent-dependent steps. Fonts containing invalid data or local font faces that are not found are ignored and the user agent loads the next font in the list.

As with other URLs in CSS, the URL can be relative, in which case it is resolved relative to the location of the style sheet containing the @font-face rule. In the case images/of SVG fonts, the URL points to an element within a document images/containing SVG font definitions. If the element reference is omitted, a reference to the first defined font is implied. Similarly, font container formats that can contain more than one font must load one and only one of the fonts for a given @font-face rule. Fragment identifiers are used to indicate which font to load; these use the PostScript name of the font as defined in [RFC8081].

src: url(fonts/simple.woff);       /* load simple.woff relative to stylesheet location */
src: url(/fonts/simple.woff);      /* load simple.woff from absolute location */
src: url(fonts/coll.otc#foo);      /* load font foo from collection coll.otc
src: url(fonts/coll.woff2#foo);    /* load font foo from woff2 collection coll.woff2
src: url(fonts.svg#simple);        /* load SVG font with id 'simple' */

External references consist of a URL, followed by an optional hint describing the format of the font resource referenced by that URL. The format hint contains a comma-separated list of format strings that denote well-known font formats. Conformant user agents must 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.

/* load WOFF font if possible, otherwise use OpenType font */
@font-face {
  font-family: bodytext;
  src: url(ideal-sans-serif.woff) format("woff"),
       url(basic-sans-serif.ttf) format("opentype");
}

Format strings defined by this specification:

Given the overlap in common usage between TrueType and OpenType, the format hints "truetype" and "opentype" must 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).

A value of "woff-variations", "truetype-variations", "opentype-variations", or "woff2-variations" imply support of the "woff", "truetype", "opentype", or "woff2" formats respectively along with additional support for font variations. Web authors can specify this format to indicate that variation support is required for correct rendering of a font. This mechanism can be used for gracefully falling back to an ancillary font when variation support is not present.

When authors would prefer to use a locally available copy of a given font and download it if it’s not, local() can be used. The locally-installed font-face-name argument to local() is a format-specific string that uniquely identifies a single font face within a larger family. The name can optionally be enclosed in quotes. If unquoted, the unquoted font family name processing conventions apply; the name must be a sequence of identifiers separated by whitespace which is converted to a string by joining the identifiers together separated by a single space.

/* regular face of Gentium */
@font-face {
  font-family: MyGentium;
  src: local(Gentium),    /* use locally available Gentium */
       url(Gentium.woff); /* otherwise, download it */
}

For OpenType and TrueType fonts, this string is used to match only the Postscript name or the full font name in the name table of locally available fonts. Which type of name is used varies by platform and font, so authors should include both of these names to assure proper matching across platforms. Platform substitutions for a given font name must not be used.

/* bold face of Gentium */
@font-face {
  font-family: MyGentium;
  src: local(Gentium Bold),    /* full font name */
       local(Gentium-Bold),    /* Postscript name */
       url(GentiumBold.woff);  /* otherwise, download it */
  font-weight: bold;
}

Just as a @font-face rule specifies the characteristics of a single font within a family, the unique name used with local() specifies a single font, not an entire font family. Defined in terms of OpenType font data, the Postscript name is found in the font’s name table, in the name record with nameID = 6 (see [OPENTYPE] for more details). The Postscript name is the commonly used key for all fonts on OSX and for Postscript CFF fonts under Windows. The full font name (nameID = 4) is used as a unique key for fonts with TrueType glyphs on Windows.

For OpenType fonts with multiple localizations of the full font name, the US English version is used (language ID = 0x409 for Windows and language ID = 0 for Macintosh) or the first localization when a US English full font name is not available (the OpenType specification recommends that all fonts minimally include US English names). User agents that also match other full font names, e.g. matching the Dutch name when the current system locale is set to Dutch, are considered non-conformant. This is done not to prefer English but to avoid matching inconsistencies across font versions and OS localizations, since font style names (e.g. "Bold") are frequently localized into many languages and the set of localizations available varies widely across platform and font version. User agents that match a concatenation of family name (nameID = 1) with style name (nameID = 2) are considered non-conformant.

This also allows for referencing faces that belong to larger families that cannot otherwise be referenced.

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

@font-face {
  font-family: jpgothic;
  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);
}

@font-face {
  font-family: SectionHeader;
  src: local("Arial Lihavoitu");  /* Finnish fullname for Arial Bold, should fail */
  font-weight: bold;
}

h2 { font-family: SectionHeader, serif; }

@font-face {
  font-family: MainText;
  src: url(gentium.eot);                     /* for use with older user agents */
  src: local("Gentium"), url(gentium.woff);  /* Overrides src definition */
}

4.4. Font property descriptors: the font-style, font-weight, and 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 meaning of the values for these descriptors are the same as those for the corresponding font properties except that relative keywords are not allowed, bolder and lighter. If these descriptors are omitted, initial values are assumed. If specified values are out of range of the accepted values of the property of the same name, the descriptor is treated as a parse error.

Ranges are accepted in these three descriptors in place of a single value. Where a single value is specified, it has the same meaning as a range with identical startpoint and endpoint. User agents must swap the computed value of the startpoint and endpoint of the range in order to forbid decreasing ranges. Both endpoints are inclusive. The ranges are used in the Font Matching Algorithm below.

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 obliquing must 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. However, variation values applied to fonts defined with '@font-face' will be clamped to both the values specified in these descriptors as well as the values supported by the font file itself.

The font descriptors defined in this section are used for selecting a font from within the set of fonts defined by @font-face rules for a given family.

Consider a family containing a single, regular face:

@font-face {
  font-family: BaskervilleSimple;
  src: url(baskerville-regular.woff);
}

Unstyled text would display using the regular face defined in the @font-face rule:

However, italic text would display in most user agents using synthetically obliqued glyphs from the regular face, since a separate italic face is not defined:

Now consider a family for which an actual italic face is defined:

@font-face {
  font-family: BaskervilleFull;
  src: url(baskerville-regular.woff);
}

@font-face {
  font-family: BaskervilleFull;
  src: url(baskerville-italic.woff);
  font-style: italic;
}

The second @font-face rule defines the font resource baskerville-italic.woff to have style attributes of normal weight, normal stretch and italic style. When displaying italic text, the user agent will use this font, since it’s the closest match for italic text. Thus, the text will display using glyphs designed by a type designer rather than using synthetically obliqued glyphs from the regular face:

See the section on font matching for more complete details of the process used to select a particular face within a font family.

4.5. Character range: the unicode-range descriptor

This descriptor defines the set of Unicode codepoints that may be supported by the font face for which it is declared. The descriptor value is a comma-delimited list of Unicode range (<urange>) values. The union of these ranges defines the set of codepoints that serves as a hint for user agents when deciding whether or not to download a font resource for a given text run.

Each <urange> value is a UNICODE-RANGE token made up of a "U+" or "u+" prefix followed by a codepoint range in one of the three forms listed below. Ranges that do not fit one of the these forms are invalid and cause the declaration to be ignored.

single codepoint (e.g. U+416)

a Unicode codepoint, represented as one to six hexadecimal digits

interval range (e.g. U+400-4ff)

represented as two hyphen-separated Unicode codepoints indicating the inclusive start and end codepoints of a range

wildcard range (e.g. U+4??)

defined by the set of codepoints implied when trailing '?' characters signify any hexadeximal digit

Individual codepoints are written using hexadecimal values that correspond to Unicode character codepoints. Unicode codepoint values must be between 0 and 10FFFF inclusive. Digit values of codepoints are ASCII case-insensitive. For interval ranges, the start and end codepoints must be within the range noted above and the end codepoint must be greater than or equal to the start codepoint.

Wildcard ranges specified with ‘?’ that lack an initial digit (e.g. "U+???") are valid and equivalent to a wildcard range with an initial zero digit (e.g. "U+0???" = "U+0000-0FFF"). Wildcard ranges that extend beyond the range of Unicode codepoints are invalid. Because of this, the maximum number of trailing '?' wildcard characters is five, even though the UNICODE-RANGE token accepts six.

Within the comma-delimited list of Unicode ranges in a unicode-range descriptor declaration, ranges may overlap. The union of these ranges defines the set of codepoints for which the corresponding font may be used. User agents must not download or use the font for codepoints outside this set. User agents may normalize the list of ranges into a list that is different but represents the same set of codepoints.

The associated font might not contain glyphs for the entire set of codepoints defined by the unicode-range descriptor. When the font is used, the effective character map is the intersection of the codepoints defined by unicode-range with the font’s character map. This allows authors to define supported ranges in terms of broad ranges without worrying about the precise codepoint ranges supported by the underlying font.

4.5.1. Using character ranges to define composite fonts

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.

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.woff) format("woff");
  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;
}

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

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

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

/* Japanese glyphs - size: 1.2MB */
@font-face {
  font-family: DroidSans;
  src: url(DroidSansJapanese.woff);
  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.woff);
  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>

4.6. Font features and variations: the font-variant, font-feature-settings, and font-variation-settings descriptors

These descriptors define initial settings that apply when the font defined by an @font-face rule is rendered. They do not affect font selection. Values are identical to those defined for the corresponding font-variant, font-feature-settings, and font-variation-settings properties defined below except that the value inherit is omitted. When multiple font feature descriptors, properties, or variations are used, the cumulative effect on text rendering is detailed in the section Font Feature and Variation Resolution below. In cases where specific values define synthesized fallback for certain font-variant subproperties, the same synthesized fallback applies when used within those values are used with the font-variant descriptor.

4.6.1. Font loading guidelines

The @font-face rule is designed to allow lazy loading of font resources that are only downloaded when used within a document. A stylesheet can include @font-face rules for a library of fonts of which only a select set are used; user agents must only download those fonts that are referred to within the style rules applicable to a given page. User agents that download all fonts defined in @font-face rules without considering whether those fonts are in fact used within a page are considered non-conformant. In cases where a font might be downloaded in character fallback cases, user agents may download a font if it’s contained within the computed value of font-family for a given text run.

@font-face {
  font-family: GeometricModern;
  src: url(font.woff);
}

p {
  /* font will be downloaded for pages with p elements */
  font-family: GeometricModern, sans-serif;
}

h2 {
  /* font may be downloaded for pages with h2 elements, even if Futura is available locally */
  font-family: Futura, GeometricModern, sans-serif;
}

In cases where textual content is loaded before downloadable fonts are available, user agents may render text as it would be rendered if downloadable font resources are not available or they may render text transparently with fallback fonts to avoid a flash of text using a fallback font. In cases where the font download fails user agents must display text, simply leaving transparent text is considered non-conformant behavior. Authors are advised to use fallback fonts in their font lists that closely match the metrics of the downloadable fonts to avoid large page reflows where possible.

4.6.2. Font fetching requirements

For font loads, user agents must use the potentially CORS-enabled fetch method defined by the [HTML5] specification for URL’s defined within @font-face rules. When fetching, user agents must use "Anonymous" mode, set the referrer source to the stylesheet’s URL and set the origin to the URL of the containing document.

Note: The implications of this for authors are that fonts will typically not be loaded cross-origin unless authors specifically takes steps to permit cross-origin loads. Sites can explicitly allow cross-site loading of font data using the Access-Control-Allow-Origin HTTP header. For other schemes, no explicit mechanism to allow cross-origin loading, beyond what is permitted by the potentially CORS-enabled fetch method, is defined or required.

/* same origin (i.e. domain, scheme, port match document) */src: url(fonts/simple.woff);

/* data url’s with no redirects are treated as same origin */
src: url("data:application/font-woff;base64,...");

/* cross origin, different domain */
/* Access-Control-Allow-Origin response header set to '*' */
src: url(http://another.example.com/fonts/simple.woff);

/* cross origin, different scheme *//* no Access-Control-xxx headers in response */
src: url(https://example.com/fonts/simple.woff);

/* cross origin, different domain */
/* no Access-Control-xxx headers in response */
src: url(http://another.example.com/fonts/simple.woff);

4.7. Controlling Font Display Per Font-Face: the font-display descriptor

The font-display descriptor for @font-face determines how a font face is displayed, based on whether and when it is downloaded and ready to use.

Note: For all of these values, user agents may use slightly different durations, or more sophisticated behaviors that can’t be directly expressed in the font-display syntax, in order to provide more useful behavior for their users. They may also provide the ability for users to override author-chosen behavior with something more desirable; for example, forcing all fonts to have a 0s block period.

auto

The font display policy is user-agent-defined.

Note: Many browsers have a default policy similar to that specified by block.

block

Gives the font face a short block period (3s is recommended in most cases) and an infinite swap period.

Note: In other words, the browser draws "invisible" text at first if it’s not loaded, but swaps the font face in as soon as it loads.

This value must only be used when rendering text in a particular font is required for the page to be usable. It must only be used for small pieces of text.

For example, badly designed "icon fonts" might associate a "⎙" (print) icon with an unrelated character like "C", so if the text is displayed with a fallback font instead there will be confusing letters scattered around the page rather than the desired icon. In this case, temporary blank spots are better than using a fallback font.

(However, the fallback font is used eventually, as having confusing letters scattered around the page is better than having links and such never show up at all.)

swap

Gives the font face an extremely small block period (100ms or less is recommended in most cases) and an infinite swap period.

Note: In other words, the browser draws the text immediately with a fallback if the font face isn’t loaded, but swaps the font face in as soon as it loads.

This value should only be used when rendering text in a particular font is very important for the page, but rendering in any font will still get a correct message across. It should only be used for small pieces of text.

For example, if a website has a custom font for rendering their logo, rendering that logo correctly is fairly important for branding purposes, but displaying the logo in any font will at least get the point across without confusion.

fallback

Gives the font face an extremely small block period (100ms or less is recommended in most cases) and a short swap period (3s is recommended in most cases).

Note: In other words, the font face is rendered with a fallback at first if it’s not loaded, but it’s swapped in as soon as it loads. However, if too much time passes, the fallback will be used for the rest of the page’s lifetime instead.

This value should be used for body text, or any other text where the use of the chosen font is useful and desired, but it’s acceptable for the user to see the text in a fallback font. This value is appropriate to use for large pieces of text.

For example, in large pieces of body text, it’s most important just to get the text rendered quickly, so the user can begin to read as quickly as possible. Further, once the user has started reading, they shouldn’t be disturbed by the text suddenly "shifting" as a new font is swapped in, as that’s distracting and annoying to re-find where one was in the text.

optional

Gives the font face an extremely small block period (100ms or less is recommended in most cases) and a 0s swap period.

If the font is not retrieved before the two durations expire, the user agent may choose to abort the font download, or download it with a very low priority. If the user agent believes it would be useful for the user, it may avoid even starting the font download, and proceed immediately to using a fallback font.

Note: In other words, the font is used if it’s already downloaded and available, but otherwise a fallback is used for the rest of the page’s lifetime instead. The font might download in the background and be available to future page loads, but if the user-agent detects that the user has very limited bandwidth, it might choose to simply never download and use the font.

This value should be used for body text, or any other text where the chosen font is purely a decorative "nice-to-have". It should be used anytime it is more important that the web page render quickly on first visit, than it is that the user wait a longer time to see everything perfect immediately.

For example, body text is perfectly readable in one of the browser default fonts, though a downloadable font face might be more attractive and mesh with the site’s aesthetics better. First time visitors to a site generally care far more about the site being quickly usable than they do about the finer points of its display, and optional provides a good behavior for them. If they return later, the desired font faces might have finished downloading, giving them the "intended" experience without slowing down either their first or subsequent visits.

Users on very slow connections might not ever receive the "intended" experience, but optional ensures they can actually use the site, rather than quitting and going elsewhere because the site takes too long to load.

4.7.1. Controlling Font Display Per Font-Family via @font-feature-values

The font-display descriptor for @font-feature-values determines how a font family is displayed, by setting the "default" font-display value for @font-face rules targeting the same font family. When font-display is omitted in an @font-face rule, the user agent uses the font-display value set via @font-feature-values for the relevant font-family if one is set, and otherwise defaults to font-display: auto.

This mechanism can be used to set a default display policy for an entire font-family, and enables developers to set a display policy for @font-face rules that are not directly under their control. For example, when a font is served by a third-party font foundry, the developer does not control the @font-face rules but is still able to set a default font-display policy for the provided font-family. The ability to set a default policy for an entire font-family is also useful to avoid the ransom note effect (i.e. mismatched font faces) because the display policy is then applied to the entire font family.

4.8. Default font language overriding: the font-language-override descriptor

This descriptor defines initial settings that apply when the font defined by an @font-face rule is rendered. It does not affect font selection. Values are identical to those defined for the font-language-override property defined below except that the value inherit is omitted. When multiple font feature descriptors, properties, or variations are used, the cumulative effect on text rendering is detailed in the section Font Feature and Variation Resolution below.

5. Font Matching Algorithm

The algorithm below describes how fonts are associated with individual runs of text. For each character in the run a font family is chosen and a particular font face is selected containing a glyph for that character.

5.1. Case sensitivity of font family names

As part of the font matching algorithm outlined below, user agents must match font family names used in style rules with actual font family names contained in fonts available in a given environment or with font family names defined in @font-face rules. User agents must match these names case insensitively, using the "Default Caseless Matching" algorithm outlined in the Unicode specification [UNICODE]. This algorithm is detailed in section 3.13 entitled "Default Case Algorithms". Specifically, the algorithm must be applied without normalizing the strings involved and without applying any language-specific tailorings. The case folding method specified by this algorithm uses the case mappings with status field "C" or "F" in the CaseFolding.txt file of the Unicode Character Database.

Note: For authors this means that font family names are matched case insensitively, whether those names exist in a platform font or in the @font-face rules contained in a stylesheet. Authors should take care to ensure that names use a character sequence consistent with the actual font family name, particularly when using combining characters such as diacritical marks. For example, a family name that contains a lowercase a (U+0061) followed by a combining ring (U+030A) will not match a name that looks identical but which uses the precomposed lowercase a-ring character (U+00E5) instead of the combining sequence.

Note: Implementors should take care to verify that a given caseless string comparison implementation uses this precise algorithm and not assume that a given platform string matching routine follows it, as many of these have locale-specific behavior or use some level of string normalization.

5.2. Matching font styles

The procedure for choosing a font for a given character in a run of text consists of iterating over the font families named 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 the given character. This is done using the character map of the font, data which maps characters to the default glyph for that character. A font is considered to support a given character if (1) the character is contained in the font’s character map and (2) if required by the containing script, shaping information is available for that character.

Some legacy fonts might include a given character in the character map but lack the shaping information (e.g. OpenType layout tables or Graphite tables) necessary for correctly rendering text runs containing that character.

Codepoint sequences consisting of a base character followed by a sequence of combining characters are treated slightly differently, see the section on cluster matching below.

For this procedure, the default face for a given font family is defined to be the face that would be selected if all font style properties were set to their initial value.

1. Using the computed font property values for a given element, the user agent starts with the first family name specified by the font-family property.

2. If the family name is a generic family keyword, 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.

3. For other family names, the user agent attempts to find the family name among fonts defined via @font-face rules and then among available installed fonts, matching names with a case-insensitive comparison as outlined in the section above. On systems containing fonts with multiple localized font family names, user agents must match any of these names independent of the underlying system locale or platform API used. If the font resources defined for a given face in an @font-face rule are either not available or contain invalid font data, then the face should be treated as not present in the family. If no faces are present for a family defined via @font-face rules, the family should be treated as missing; matching a platform font with the same name must not occur in this case.

4. If a font family match occurs, the user agent assembles the set of font faces in that family and then narrows the set to a single face using other font properties in the order given below. Fonts might be present in this group which can support a range of font-stretch, font-style, or font-weight properties. In this case, the algorithm proceeds as if each supported combination of values are a unique font in the set. If such a font is ultimately selected by this algorithm, particular values for font-stretch, font-style, and font-weight must be applied before any layout or rendering occurs. The application of these values must be applied in the Apply font matching variations step detailed in Font Feature and Variation Resolution. A group of faces defined via @font-face rules with identical font descriptor values but differing unicode-range values are considered to be a single composite face for this step:

   1. font-stretch is tried first. If a font does not have any concept of varying strengths of stretch values, its stretch value is mapped according table in the property definition. If the matching set includes faces with width values containing the font-stretch desired value, faces with width values which do not include the desired width value are removed from the matching set. If there is no face which contains the desired value, a stretch value is chosen using the rules below:

      • If the desired stretch value is less than or equal to 100, stretch values below the desired stretch value are checked in descending order followed by stretch values above the desired stretch value in ascending order until a match is found.

      • Otherwise, stretch values above the desired stretch value are checked in ascending order followed by stretch values below the desired stretch value in descending order until a match is found.

      Once the closest matching width has been determined by this process, faces with widths which do not include this determined width are removed from the matching set.

      This search algorithm can be thought of as a distance function, where the lowest-distance value present in the font family is selected, and all fonts not including that value are eliminated.

      Consider a font family with three fonts, named A, B, and C, each with associated supported ranges for the font-stretch descriptor. If an element is styled with "font-stretch: 125", the search algorithm can be visualized as follows:

      

      The font stretch ranges supported by fonts A, B, and C are shown in the graph above. As you can see, because font B contains the minimum stretch value across the entire family, font B would be selected by this algorithm. However, if font B were somehow eliminated from the family, font C would then contain the lowest distance in the family, so it would be selected.

      Similar to the previous example, here is the conceptual distance graph for an element styled with "font-stretch: 75":

      

      As you can see, because font B contains the minimum stretch value across the entire family, font B would be selected by this algorithm. However, if font B were somehow eliminated from the family, font A would then contain the lowest distance in the family, so it would be selected.

   2. font-style is tried next. If a font does not have any concept of varying strengths of italics or oblique angles, its style is mapped according to the description in the font-style property definition.

      If the value of font-style is italic:

      1. If the matching set includes faces with italic values containing the mapped value of italic, faces, then faces with italic values which do not include the desired italic mapped value are removed from the matching set.

      2. Otherwise, italic values above the desired italic value are checked in ascending order followed by italic values below the desired italic value, until 0 is hit. Only positive values of italic values are checked in this stage.

      3. If no match is found, oblique values greater than or equal to 20deg are checked in ascending order followed by oblique values below 20deg in descending order, until 0 is hit. Only positive values of oblique values are checked in this stage.

      4. If no match is found, italic values less than or equal to 0 are checked in descending order until a match is found.

      5. If no match is found, oblique values less than or equal to 0deg are checked in descending order until a match is found.

         Similar to the previous example, here is the conceptual distance graph for an element styled with "font-style: italic":

         

         As you can see, because font D contains the minimum italic value across the entire family, font D would be selected by this algorithm. However, if font D were somehow eliminated from the family, font E would then contain the lowest distance in the family, so it would be selected. If E were eliminated, C would be selected. If C were eliminated, font B would not be chosen immediately; instead, oblique values would be consulted and an oblique value might be chosen. However, if no oblique value is chosen, font B would then be selected, followed by font A.

      If the value of font-style is oblique and the requested angle is greater than or equal to 20deg,

      1. If the matching set includes faces with oblique values containing the value of oblique, faces with oblique values which do not include the desired oblique value are removed from the matching set.

      2. Otherwise, oblique values above the desired oblique value are checked in ascending order followed by oblique values below the desired oblique value, until 0 is hit. Only positive values of oblique values are checked in this stage.

      3. If no match is found, italic values greater than or equal to 1 are checked in ascending order followed by italic values below 1 in descending order, until 0 is hit. Only positive values of italic values are checked in this stage.

      4. If no match is found, oblique values less than or equal to 0deg are checked in descending order until a match is found.

      5. If no match is found, italic values less than or equal to 0 are checked in descending order until a match is found.

         Similar to the previous example, here is the conceptual distance graph for an element styled with "font-style: oblique 40deg":

         

         As you can see, because font D contains the minimum oblique value across the entire family, font D would be selected by this algorithm. However, if font D were somehow eliminated from the family, font E would then contain the lowest distance in the family, so it would be selected. If E were eliminated, C would be selected. If C were eliminated, font B would not be chosen immediately; instead, italic values would be consulted and an italic value might be chosen. However, if no italic value is chosen, font B would then be selected, followed by font A.

      If the value of font-style is oblique and the requested angle is greater than or equal to 0deg and less than 20deg,

      1. If the matching set includes faces with oblique values containing the value of oblique, faces with oblique values which do not include the desired oblique value are removed from the matching set.

      2. Otherwise, oblique values below the desired oblique value are checked in descending order until 0 is hit, followed by oblique values above the desired oblique value. Only positive values of oblique values are checked in this stage.

      3. If no match is found, italic values less than 1 are checked in descending order until 0 is hit, followed by italic values above 1 in ascending order. Only positive values of italic values are checked in this stage.

      4. If no match is found, oblique values less than or equal to 0deg are checked in descending order until a match is found.

      5. If no match is found, italic values less than or equal to 0 are checked in descending order until a match is found.

      Similar to the previous example, here is the conceptual distance graph for an element styled with "font-style: oblique 13deg":

      

      As you can see, because font D contains the minimum oblique value across the entire family, font D would be selected by this algorithm. However, if font D were somehow eliminated from the family, font C would then contain the lowest distance in the family, so it would be selected. If C were eliminated, E would be selected. If E were eliminated, font B would not be chosen immediately; instead, italic values would be consulted and an italic value might be chosen. However, if no italic value is chosen, font B would then be selected, followed by font A.

   If the value of font-style is oblique and the requested angle is less than 0deg and greater than -20deg, follow the steps above, except with the negated values and opposite directions. If the value of font-style is oblique and the requested angle is less than or equal to -20deg, follow the steps above, except with the negated values and opposite directions.

   If the value of font-style is normal,

   1. Oblique values greater than or equal to 0 are checked in ascending order.

   2. If no match is found, italic values greater than or equal to 0 are checked in ascending

   3. If no match is found, oblique values less than 0deg are checked in descending order until a match is found.

   4. If no match is found, italic values less than 0 are checked in descending order until a match is found.

   Similar to the previous example, here is the conceptual distance graph for an element styled with "font-style: normal":

   

   As you can see, because font C contains the minimum oblique value across the entire family, font C would be selected by this algorithm. However, if font C were somehow eliminated from the family, font B would not be chosen immediately; instead, italic values would be consulted and an italic value might be chosen. However, if no italic value is chosen, font B would then be selected, followed by font A.

   If an oblique angle was found in the above search, all faces which don’t include that oblique angle are excluded from the matching set. Otherwise, if an italic value was found in the above search, all faces which don’t include that italic value are excluded from the matching set.

   User Agents are not required to distinguish between italic and oblique fonts. In such User Agents, the font-style matching steps above are performed by mapping both italic values and oblique angles onto a common scale. The exact nature of this mapping is undefined, however, an italic value of 1 must map to the same value that an oblique angle of 20deg maps to. Within font families defined via @font-face rules, italic and oblique faces must be distinguished using the value of the font-style descriptor.

   For families that lack any italic or oblique faces, user agents may create artificial oblique faces, if this is permitted by the value of the font-synthesis property.

5. font-weight is matched next. If a font does not have any concept of varying strengths of weights, its weight is mapped according list in the property definition. If bolder/lighter relative weights are used, the effective weight is calculated based on the inherited weight value, as described in the definition of the font-weight property. If the matching set after performing the steps above includes faces with weight values containing the font-weight desired value, faces with weight values which do not include the desired font-weight value are removed from the matching set. If there is no face which contains the desired value, a weight value is chosen using the rules below:

   • If the desired weight is inclusively between 400 and 500, weights greater than or equal to the target weight are checked in ascending order until 500 is hit and checked, followed by weights less than the target weight in descending order, followed by weights greater than 500, until a match is found.

   • If the desired weight is less than 400, weights less than or equal to 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 greater than or equal to the desired weight are checked in ascending order followed by weights below the desired weight in descending order until a match is found.

   Similar to the previous example, here is the conceptual distance graph for an element styled with "font-weight: 400":

   

   As you can see, because font B contains the minimum distance across the entire family, font B would be selected by this algorithm. However, if font B were somehow eliminated from the family, font D would then contain the lowest distance in the family, so it would be selected. If D were eliminated, A would be selected, followed by fonts C and then E.

   Similar to the previous example, here is the conceptual distance graph for an element styled with "font-weight: 450":

   

   As you can see, because font C contains the minimum distance across the entire family, font C would be selected by this algorithm. However, if font C were somehow eliminated from the family, font D would then contain the lowest distance in the family, so it would be selected. If D were also eliminated, B would be selected, followed by fonts A and then E.

   Similar to the previous example, here is the conceptual distance graph for an element styled with "font-weight: 500":

   

   As you can see, because font D contains the minimum distance across the entire family, font D would be selected by this algorithm. However, if font D were somehow eliminated from the family, font B would then contain the lowest distance in the family, so it would be selected. If B were eliminated, C would be selected, followed by fonts A and then E.

   Similar to the previous example, here is the conceptual distance graph for an element styled with "font-weight: 300":

   

   As you can see, because font B contains the minimum distance across the entire family, font B would be selected by this algorithm. However, if font B were somehow eliminated from the family, font A would then contain the lowest distance in the family, so it would be selected. If A were eliminated, C would be selected.

   Once the closest matching weight has been determined by this process, faces with weights which do not include this determined weight are removed from the matching set.

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

   Note that more than one font might be remaining in the matching set after performing the above steps. If so, the user agent must choose a single font from the matching set and continue these steps with it. The choice of which font to choose can differ between multiple user agents and multiple operating system platforms; however, it must not differ between two elements in the same document.

7. If the matched face is defined via @font-face rules, user agents must use the procedure below to select a single font:

   1. If the font resource has not been loaded and the range of characters defined by the unicode-range descriptor value includes the character in question, load the font.

   2. After downloading, if the effective character map supports the character in question, select that font.

   When the matched face is a composite face, user agents must use the procedure above on each of the faces in the composite face in reverse order of @font-face rule definition.

   While the download occurs, user agents must either wait until the font is downloaded or render once with substituted font metrics and render again once the font is downloaded.

8. 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 three steps repeated. Glyphs from other faces in the family are not considered. The only exception is that user agents may optionally substitute a synthetically obliqued version of the default face if that face supports a given glyph and synthesis of these faces is permitted by the value of the font-synthesis property. For example, a synthetic italic version of the regular face might be used if the italic face doesn’t support glyphs for Arabic.

9. If there are no more font families to be evaluated and no matching face has been found, then the user agent performs a installed font fallback procedure to find the best match for the character to be rendered. The result of this procedure can vary across user agents.

10. 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, displaying either a symbolic representation of the missing glyph (e.g. using a Last Resort Font) or using the missing character glyph from a default font.

Optimizations of this process are allowed provided that an implementation behaves as if the algorithm had been followed exactly. Matching occurs in a well-defined order to ensure that the results are as consistent as possible across user agents, given an identical set of available fonts and rendering technology.

The first available font, used for example in the definition of font-relative lengths such as ex and ch or in the definition of the line-height property is defined to be the first available font that would match the U+0020 (space) character given font families in the font-family list (or a user agent’s default font if none are available).

5.3. Cluster matching

Import from level 3

5.4. Character handling issues

Import from level 3

6. Font Feature Properties

Modern font technologies support a variety of advanced typographic and language-specific font features. Using these features, a single font can provide glyphs for a wide range of ligatures, contextual and stylistic alternates, tabular and old-style figures, small capitals, automatic fractions, swashes, and alternates specific to a given language. To allow authors control over these font capabilities, the font-variant property has been expanded for CSS3. It now functions as a shorthand for a set of properties that provide control over stylistic font features.

Import these sections from level 3, once it goes to Proposed Rec; stubs added as link targets for font tests moved to Level 4

6.1. Glyph selection and positioning

This section is non-normative

Simple fonts used for displaying Latin text use a very basic processing model. Fonts contain a character map which maps each character to a glyph for that character. Glyphs for subsequent characters are simply placed one after the other along a run of text. Modern font formats such as OpenType and AAT (Apple Advanced Typography) use a richer processing model. The glyph for a given character can be chosen and positioned not just based on the codepoint of the character itself, but also on adjacent characters as well as the language, script, and features enabled for the text. Font features may be required for specific scripts, or recommended as enabled by default or they might be stylistic features meant to be used under author control. The point at which font selection and positioning happens in the overall order of text processing operations (such as text transformation, text orientation and text alignment) is described in CSS Text 3 § Text Processing Order of Operations.

For a good visual overview of these features, see the [OPENTYPE-FONT-GUIDE]. For a detailed description of glyph processing for OpenType fonts, see [WINDOWS-GLYPH-PROC].

Stylistic font features can be classified into two broad categories: ones that affect the harmonization of glyph shapes with the surrounding context, such as kerning and ligature features, and ones such as the small-caps, subscript/superscript and alternate features that affect shape selection.

The subproperties of font-variant listed below are used to control these stylistic font features. They do not control features that are required for displaying certain scripts, such as the OpenType features used when displaying Arabic or Indic language text. They affect glyph selection and positioning, but do not affect font selection as described in the font matching section (except in cases required for compatibility with CSS 2.1).

To assure consistent behavior across user agents, the equivalent OpenType property settings are listed for individual properties and are normative. When using other font formats these should be used as a guideline to map CSS font feature property values to specific font features.

6.2. Language-specific display

OpenType also supports language-specific glyph selection and positioning, so that text can be displayed correctly in cases where the language dictates a specific display behavior. Many languages share a common script, but the shape of certain letters can vary across those languages. For example, certain Cyrillic letters have different shapes in Russian text than in Bulgarian. In Latin text, it’s common to render "fi" with an explicit fi-ligature that lacks a dot on the "i". However, in languages such as Turkish which uses both a dotted-i and a dotless-i, it’s important to not use this ligature or use a specialized version that contains a dot over the "i". The example below shows language-specific variations based on stylistic traditions found in Spanish, Italian and French orthography:

If the content language of the element is known according to the rules of the document language, user agents are required to infer the OpenType language system from the content language and use that when selecting and positioning glyphs using an OpenType font.

For OpenType fonts, in some cases it may be necessary to explicitly declare the OpenType language to be used, for example when displaying text in a given language that uses the typographic conventions of another language or when the font does not explicitly support a given language but supports a language that shares common typographic conventions. The font-language-override property is used for this purpose.

6.3. Kerning: the font-kerning property

6.4. Ligatures: the font-variant-ligatures property

6.5. Subscript and superscript forms: the font-variant-position property

6.6. Capitalization: the font-variant-caps property

6.7. Numerical formatting: the font-variant-numeric property

6.8. Alternates and swashes: the font-variant-alternates property

For any given character, fonts can provide a variety of alternate glyphs in addition to the default glyph for that character. This property provides control over the selection of these alternate glyphs.

For many of the property values listed below, several different alternate glyphs are available. How many alternates are available and what they represent is font-specific, so these are each marked font specific in the value definitions below. Because the nature of these alternates is font-specific, the @font-feature-values rule is used to define values for a specific font family or set of families that associate a font-specific numeric with a custom , which is then used in this property to select specific alternates:

@font-feature-values Noble Script { @swash { swishy: 1; flowing: 2; } }
p {
  font-family: Noble Script;
  font-variant-alternates: swash(flowing); /* use swash alternate #2 */
}

When a particular has not been defined for a given family or for a particular feature type, the computed value must be the same as if it had been defined. However, property values that contain these undefined identifiers must be ignored when choosing glyphs.

/* these two style rules are effectively the same */
p { font-variant-alternates: swash(unknown-value); } /* not a defined value, ignored */
p { font-variant-alternates: normal; }

This allows values to be defined and used for a given set of font families but ignored if fallback occurs, since the font family name would be different. If a given value is outside the range supported by a given font, the value is ignored. These values never apply to generic font families.

Individual values have the following meanings:

normal

None of the features listed below are enabled.

historical-forms

Enables display of historical forms (OpenType feature: hist).

stylistic(<feature-value-name>)

Enables display of stylistic alternates (font specific, OpenType feature: salt <feature-index>).

styleset(<feature-value-name> #)

Enables display with stylistic sets (font specific, OpenType feature: ss<feature-index> OpenType currently defines ss01 through ss20).

character-variant(<feature-value-name> #)

Enables display of specific character variants (font specific, OpenType feature: cv<feature-index> OpenType currently defines cv01 through cv99).

swash(<feature-value-name>)

Enables display of swash glyphs (font specific, OpenType feature: swsh <feature-index>, cswh <feature-index>).

ornaments(<feature-value-name>)

Enables replacement of default glyphs with ornaments, if provided in the font (font specific, OpenType feature: ornm <feature-index>). Some fonts may offer ornament glyphs as alternates for a wide collection of characters; however, displaying arbitrary characters (e.g., alphanumerics) as ornaments is poor practice as it distorts the semantics of the data. Font designers are encouraged to encode all ornaments (except those explicitly encoded in the Unicode Dingbats blocks, etc.) as alternates for the bullet character (U+2022) to allow authors to select the desired glyph using ornaments.

annotation(<feature-value-name>)

Enables display of alternate annotation forms (font specific, OpenType feature: nalt <feature-index>).

6.9. Defining font specific alternates: the @font-feature-values rule

Moved to Level 4; port the text for this from Fonts 3 .src to Fonts 4 .bs

6.10. East Asian text rendering: the font-variant-east-asian property

6.11. Overall shorthand for font rendering: the font-variant property

6.12. Low-level font feature settings control: the font-feature-settings property

6.13. Font language override: the font-language-override property

Normally, authors can control the use of language-specific glyph substitutions and positioning by setting the content language of an element, as described above:

<!-- Display text using S’gaw Karen specific features --><p lang="ksw">...</p>

In some cases, authors may need to specify a language system that differs from the content language, for example due to the need to mimic another language’s typographic traditions. The font-language-override property allows authors to explicitly specify the language system of the font, overriding the language system implied by the content language.

Values have the following meanings:

normal

specifies that when rendering with OpenType fonts, the content language of the element is used to infer the OpenType language system

<string>

single three-letter case-sensitive OpenType language system tag, specifies the OpenType language system to be used instead of the language system implied by the language of the element

Unknown OpenType language system tags are silently ignored, and do not affect glyph selection and placement.

<body lang="tr">
<h4>Madde 9</h4>
<p>Hiç kimse keyfi olarak tutuklanamaz, alıkonulanamaz veya sürülemez.</p>

<body lang="mk">     <!-- Macedonian lang code -->
body { font-language-override: "SRB"; /* Serbian OpenType language tag */ }

<h4>Члeн 9</h4>
<p>Никoj чoвeк нeмa дa бидe пoдлoжeн нa прoизвoлнo aпсeњe, притвoр или прoгoнувaњe.</p>

7. Font Feature and Variation Resolution

As described in the previous section, font features and variations can be enabled in a variety of ways, either via the use of font-variant, font-feature-settings, fontfont-variation-settings in a style rule or within an @font-face rule. The resolution order for the union of these settings is defined below. Features defined via CSS properties are applied on top of layout engine default features.

7.1. Default features

For OpenType fonts, user agents must enable the default features defined in the OpenType documentation for a given script and writing mode. Required ligatures, common ligatures and contextual forms must be enabled by default (OpenType features: rlig, liga, clig, calt), along with localized forms (OpenType feature: locl), and features required for proper display of composed characters and marks (OpenType features: ccmp, mark, mkmk). These features must always be enabled, even when the value of the font-variant and font-feature-settings properties is normal. Individual features are only disabled when explicitly overridden by the author, as when font-variant-ligatures is set to no-common-ligatures.

For handling complex scripts such as Arabic, Mongolian or Devanagari additional features are required. For upright text within vertical text runs, vertical alternates (OpenType feature: vert) must be enabled.

7.2. Feature and variation precedence

General and font specific font feature property settings are resolved in the order below, in ascending order of precedence. This ordering is used to construct a combined list of font features that affect a given text run.

1. Font features enabled by default, including features required for a given script.

2. Font variations as enabled by the font-weight, font-stretch, and font-style properties.

   The application of the value enabled by font-style is affected by font selection, because this property might select an italic or an oblique font. The value applied is the closest matching value as determined by the font matching algorithm. User Agents must apply at most one value due to the font-style property; both "ital" and "slnt" values should not be set together.

   If the selected font is defined in an @font-face rule, then the values applied at this step should be clamped to the value of the font-weight, font-stretch, and font-style descriptors in that @font-face rule.

   Then, the values applied in this step should be clamped (possibly again) to the values that are supported by the font.

3. The language specified by the inherited value of lang/xml:lang

4. If the font is defined via an @font-face rule, the font language override implied by the font-language-override descriptor in the @font-face rule.

5. If the font is defined via an @font-face rule, the font variations implied by the font-variation-settings descriptor in the @font-face rule.

6. If the font is defined via an @font-face rule, the font features implied by the font-feature-settings descriptor in the @font-face rule.

7. The font language override implied by the value of the font-language-override property.

8. Font variations implied by the value of the font-optical-sizing property.

9. Font features implied by the value of the font-variant property, the related font-variant subproperties and any other CSS property that uses OpenType features (e.g. the font-kerning property).

10. Feature settings determined by properties other than font-variant or font-feature-settings. For example, setting a non-default value for the letter-spacing property disables common ligatures.

11. Font variations implied by the value of the font-variation-settings property. These values should be clamped to the values that are supported by the font.

12. Font features implied by the value of font-feature-settings property.

This ordering allows authors to set up a general set of defaults for fonts within their @font-face rules, then override them with property settings for specific elements. General property settings override the settings in @font-face rules and low-level font feature settings override font-variant property settings.

For situations where the combined list of font feature settings contains more than one value for the same feature, the last value is used. When a font lacks support for a given underlying font feature, text is simply rendered as if that font feature was not enabled; font fallback does not occur and no attempt is made to synthesize the feature except where explicitly defined for specific properties.

7.3. Feature precedence examples

body {
  font-variant-numeric: proportional-nums;
}

table.prices td {
  font-variant-numeric: tabular-nums;
}

@font-face {
  font-family: MainText;
  src: url(http://example.com/font.woff);
  font-variant: oldstyle-nums proportional-nums styleset(1,3);
}

body {
  font-family: MainText, Helvetica;
}

table.prices td {
  font-variant-numeric: tabular-nums;
}

@font-face {
  font-family: BodyText;
  src: local("HiraMaruPro-W4");
  font-variant: proportional-width;
  font-feature-settings: "ital"; /* Latin italics within CJK text feature */
}

body { font-family: BodyText, serif; }

@font-face {
  font-family: main;
  src: url(fonts/ffmeta.woff) format("woff");
  font-variant: discretionary-ligatures;
}

body         { font-family: main, Helvetica; }
span.special { font-variant-ligatures: no-discretionary-ligatures; }

body         { font-family: main, Helvetica; }
span         { font-feature-settings: "dlig"; }
span.special { font-variant-ligatures: no-discretionary-ligatures; }

8. Font Variation Properties

Note: The technology in use in this section is named "font variations." An instance of one such font as a "variable font."

8.1. Optical sizing control: the font-optical-sizing property

Typographically, text rendered at different sizes often benefits from slightly different visual representations. For example, to aid reading at small text sizes, strokes are often thicker with larger serifs. Larger text often has a more delicate figure with more contrast between thicker and thinner strokes.

auto

The user agent may modify the shape of glyphs based on the font-size and the pixel density of the screen. For OpenType and TrueType fonts using font variations, this is often done by using the "opsz" font variation.

none

The user agent must not modify the shape of glyphs for optical size.

font-size must be considered when selecting a variation value for the "opsz" axis, but other signals may also be considered.

Note: User Agents are expected to supply a value for the "opsz" axis which is close to the used value for font-size. However, User Agents might wish to consider other factors such as pixel density of the screen, or the solid angle the text subtends in the viewer’s retina. Experiments have shown, however, that disregarding these other ancillary factors and using only font-size might be the best way for a User Agent to select this value.

Pixel density as well as visual size of the text may influence the variation value chosen for font-optical-sizing. When either pixel density or visual size of the text changes in response to a user operation or style change, user agents must not choose a new value for this variation value unless the change is layout-causing. User agents are free to determine which changes are layout-causing.

Note: Some user operations, such as pinch-zoom, can be considered not-layout-causing if they do not cause text to reflow. However, other user operations, such as increasing text size for accessiblity purposes, can be considered layout-causing because they cause text to reflow. Similarly, the transform property can be considered not-layout-causing because transforms generally do not cause text to reflow. Each user-agent is free to decide whether or not each operation is layout-changing or not.

User Agents must not synthesize optical sizing when it is not performed by the font directly.

User Agents must not select a value for the "opsz" axis which is not supported by the font used for rendering the text. This can be accomplished by clamping a chosen value to the range supported by the font.

8.2. Low-level font variation settings control: the font-variation-settings property

This property provides low-level control over OpenType or TrueType font variations. It is intended as a way of providing access to font variations that are not widely used but are needed for a particular use case.

When possible, authors should generally use the other properties related to font variations (such as font-optical-sizing) whenever possible and only use this property for special cases where its use is the only way of accessing a particular infrequently used font variation.

A value of normal means that no change in glyph shape, matching, or positioning occurs due to this property.

The <string> is a case-sensitive OpenType or TrueType variation axis name. As specified in the OpenType / TrueType specifications, axis names contain four ASCII characters. Axis name strings longer or shorter than four characters, or containing characters outside the U+20–7E codepoint range are invalid. Axis names need only match an axis tag defined in the font, so they are not limited to explicitly registered OpenType / TrueType variation axes. Fonts defining custom axis names should follow the name rules defined in the OpenType specification.

Axis values not present in the font are ignored and therefore have no effect; a user agent must not attempt to synthesize fallback behavior based on these axis tags. Other axis values within the same CSS font-variation-settings statement are not ignored.

Axis values greater or less than the range supported by the font are clamped to the closest value supported by the font.

Values are allowed to be fractional or negative.

If the same axis name appears more than once, the value associated with the last appearance supersedes any previous value for that axis. This deduplication is observable by accessing the computed value of this property.

Although specifically defined for OpenType / TrueType variations, variation axes for other modern font formats that support font variations might be added in the future. Where possible, variations defined for other font formats should attempt to follow the pattern of registered variation axes.

Animating font-variation-settings is possible using the following mechanism. Two declarations of font-feature-settings can be animated between if they are "like". "Like" declarations are ones where the same set of properties appear (in any order). Because succesive duplicate properties are applied instead of prior duplicate properties, two declarations can be "like" even if they have differing number of properties. If two declarations are "like" then animation occurs pairwise between corresponding values in the declarations. Otherwise, animation is not possible. In this situation, the "from" values of the animation are swapped to the "to" values at an unspecified time during the animation.

9. Color Font Support

Color fonts allow for font files to describe not just the contours describing the edges of glyphs, but also the colors present inside the glyphs.

Add a picture.

9.1. Controlling Color Font Palettes: The font-palette property

Many color font file formats allow colors within glyphs to be parameterized. In these fonts, colors are referenced by index when describing the geometry of each glyph. These indices are resolved within a current active palette using a lookup table present inside the font. However, many fonts contain multiple palettes, each containing a set of complimentary colors chosen by the font designer to provide pleasing visual results.

normal

User-Agents attempt to treat the color font as closely as possible to a non-color font. In particular, user-agents use a palette which will yield the best default result for reading. User-agents may take the computed value of the color property into consideration when making this decision. User agents may also construct and use a palette not defined in the font.

light

Some color font formats include metadata marking certain palettes as applicable on a light (close to white) background. This keyword causes the user-agent to use the first available palette in the font file marked this way. If the font file format does not account for this metadata, or no palette in the font is marked this way, this value behaves as normal.

dark

Some color font formats include metadata marking certain palettes as applicable on a dark (close to black) background. This keyword causes the user-agent to use the first available palette in the font file marked this way. If the font file format does not account for this metadata, or no palette in the font is marked this way, this value behaves as normal.

<palette-identifier>

This value identifies an author-define palette to use. Users can define a palette by using the @font-palette-values rule. If no applicable @font-palette-values rule is present, this value behaves as normal.

Add examples and pictures.

9.2. User-defined font color palettes: The @font-palette-values rule

The @font-palette-values rule defines a color palette and associates that color palette with a specific font. This allows a web author to select arbitrary colors to use inside a color font rather than being limited to the preexisting palettes inside font files. In addition, this rule’s association with a specific font allows a name of a palette to apply differently to different fonts, which allows similar colors to be used across multiple fonts when multiple fonts are used in an element (i.e. for font fallback). A web author might wish to create multiple palettes for a single font in order to create multiple themes for their web content. A web author might also wish to create matching palettes for multiple fonts to achieve a consistent design across a collection of different fonts.

A @font-palette-values rule represents a palette of colors used in a font. A palette consists of an ordered collection of colors. Using the @font-palette-values allows a web author to reference a palette existing within a font as well as creating a palette populated with author-defined colors. In addition, it allows overriding a set of colors from a palette in the font with colors described by the web author.

The @font-palette-values rule consists of the @font-palette-values at-keyword followed by a block of descriptor declarations. It has the following syntax:

@font-palette-values <custom-ident> {
  <declaration-list>
}

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

@font-palette-values Augusta {
  font-family: Handover Sans;
  base-palette: 3;
  color-1: rgb(43, 12, 9);
  color-3: var(--highlight);
}

The presence of a particular descriptor within in @font-palette-values has semantic meaning; missing descriptors are not filled in with default values. These descriptors apply solely within the context of the @font-palette-values rule in which they are defined, and do not apply to document language elements. When a given descriptor occurs multiple times in a given @font-palette-values rule, only the last descriptor declaration is used and all prior declarations for that descriptor are ignored.

A given set of @font-palette-values rules define which author-defined palettes are available for use within the documents that contain these rules.

An author-defined font color palette is only available to the documents that reference it. Using an author-defined color palette outside of the documents that reference it would constitute 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.

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-palette-values rules require a font-family descriptor; if it is missing, the @font-palette-values rule is invalid and must be ignored entirely.

In cases where user agents have limited platform resources, do not implement support for color fonts, or implement the ability to disable color fonts, @font-palette-values rules must simply be ignored; the behavior of individual descriptors as defined in this specification should not be altered.

9.3. Font family: the font-family descriptor

This descriptor defines the font family name that this palette applies to. This palette will only ever be applied to the font with this name. The value of this descriptor matches the definition of the <family-name> for the font-family property. This means that only named font families are allowed and rules that including generic or installed fonts in the list of font families are syntax errors. If syntax errors occur within the font family list, the entire rule must be ignored.

9.4. Specifying the base palette: the base-palette descriptor

This descriptor specifies a palette in the font which the containing @font-palette-values rule uses as an initial value. If no <integer> keys are present in the @font-palette-values rule, then the @font-palette-values rule represents the palette in the font with the same index as the value of this descriptor. If <integer> keys are present in the @font-palette-values rule, each one of those descriptors overrides a single color in the color palette represented by this @font-palette-values block.

@font-palette-values Augusta {
  font-family: Handover Sans;
  base-palette: 3;
}

If this descriptor is not present in the @font-palette-values, or if the font does not contain a palette at the index of the value of base-palette, it behaves as if 0 were specified. If a font does not contain any color palettes, no colors are included in the initial color palette represented by this @font-palette-values rule. Colors can be added to the color palette by using the <integer> descriptor in the @font-palette-values rule.

9.5. Overriding a color in the palette: The 'color-<integer>' descriptors

This descriptor overrides or adds a color to the initial color palette represented by this @font-palette-values rule. If the initial color palette represented by the @font-palette-values rule (i.e. by using the base-palette descriptor) already includes a color at the index of this descriptor’s key, that color is overwritten by the color specified in this descriptor’s value. Otherwise, a new color is added to this color palette at the index of this descriptor’s key.

@font-palette-values Augusta {
  font-family: Handover Sans;
  color-1: rgb(43, 12, 9);
  color-2: rgb(208, 112, 96);
  color-3: var(--highlight);
}

The parsing rules for these descriptors are as follows:

1. The descriptor must start with the string "color-".

2. If there is nothing remaining in the string, the descriptor is invalid.

3. Otherwise, if the next character is a 0, the presence of anything after the 0 results in an invalid descriptor.

4. Otherwise, if the next character is a non-zero digit (1 through 9), the remainder of the string must be digits.

5. Otherwise, it is an invalid descriptor.

Using these rules, the non-negative integers prefixed with "color-" are valid identifiers.

Integers greater than 65534 in a color-<integer> descriptor are invalid.

These descriptors are zero-indexed, so the initial palette in the font is represented by the color-0 descriptor.

Using CSS Variables is explicitly expected to be valid in the value of this descriptor. Using CSS Variables is disallowed in the key of this descriptor. CSS Variables are resolved in the context of the element to which the font-palette property applies. This means that using font-palette with the same value on two different elements might result in different used palettes because the value of variables inside the @font-palette-values rule might apply differently in the context of those two elements.

9.6. Selecting the text presentation style: The font-variant-emoji property

Bikeshed the values.

This property allows web authors to select whether emoji presentation or text presentation is used for certain emoji code points. Traditionally, these presentation styles were selected by appending Variation Selector 15 (U+FE0E) or Variation Selector 16 (U+FE0F) to certain code points. However, font-variant-emoji allows web authors to set a default presentation style which can replace the variation selectors.

Only the code points listed by Unicode as contributing to a Unicode Presentation Sequence are affected by this property. Within this CSS specification, these characters are referred to as Presentation Participating Code Points. This property has no effect on any other characters.

This property is expected to affect font fallback; however, the exact nature of the interaction of font fallback with font-variant-emoji is explicitly unspecified. However, a variation selector must be included in a previous cluster as defined by the cluster matching section above. Therefore, the presence of a variation selector is treated as ancillary data to inform the font fallback routine. A natural result of this behavior is that a variation selector must not be rendered in a different font than the previous character.

Even when font-variant-emoji is used, the presence of Variation Selector 15 (U+FE0E) or Variation Selector 16 (U+FE0F) in the contents of an element override the rendering specified in font-variant-emoji. Therefore, font-variant-emoji sets a default presentation which the text being rendered can opt out of.

Note: Different platforms have different conventions about how to handle emoji presentation sequences. A cross-platform UA might wish to follow the conventions of each inividual platform, or it might wish to use the same approach on all platforms. When tasked with a request for an emoji style rendering, a UA might wish to disregard fonts which do not include color tables. A different UA might wish instead to use the same mechanical cluster fallback algorithm that it would use for any arbitrary cluster.

Variation selectors other than FE0E VARIATION SELECTOR-15 and U+FE0F VARIATION SELECTOR-16 must not have any affect on font selection. If one of these variation selectors is present, but unsupported by the font previously selected, the variation selector is ignored.

BCP47’s -u- extension to the language tag accepted by lang or xml:lang should not be considered when the user-agent decides whether to use emoji presentation or text presentation for a particular character.

auto

User Agents can choose to draw a Presentation Participating Code Point in either emoji style or text style. User Agents may wish to follow the guidance of the Unicode Consortium when performing this decision. User agents also may wish to follow platform conventions when performing this decision.

text

Code points are rendered as if U+FE0E VARIATION SELECTOR-15 was appended to every Presentation Participating Code Point.

emoji

Code points are rendered as if U+FE0F VARIATION SELECTOR-16 was appended to every Presentation Participating Code Point.

@font-face {
  font-family: "Custom Emoji";
  src: url("CustomEmoji.ttf") format("truetype");
}
...
<div style="font-family: 'Custom Emoji'; font-variant-emoji: emoji;">&#x1F6CB;</div>

10. Font Taxonomy

A given font may belong in one or more of the following categories:

10.1. Installed Fonts

A font may be installed globally on a device. Such fonts are generally accessible in any application, even applications which have no concept of CSS. The file or files backing the font object exist on the user’s device, not as a remote resource.

Installed Fonts must not be Web Fonts, and Web Fonts must not be Installed Fonts.

10.2. Web Fonts

• @font-face rules

• A FontFace member of the Document’s FontFaceSet

A Web Font must not be accessible in any other Document from the one which either is associated with the @font-face rule or owns the FontFaceSet. Other applications on the device must not be able to access Web Fonts.

Installed Fonts must not be Web Fonts, and Web Fonts must not be Installed Fonts.

Web Fonts shadow Installed Fonts, so if an Installed Font has the same family name as a Web Font, the Installed Font is not accessible.

10.3. Preinstalled Fonts and User-Installed Fonts

Users may choose to install fonts on their devices. User-Installed Fonts are installed by an explicit action by the user, such as clicking an "Install" button or copying a file into a particular directory on their device. Such fonts are User-Installed Fonts and also are Installed Fonts. Web content authors should not expect the presence of user-installed fonts, because there is no guarantee any user will have performed the action to install a specific font. User Agents may choose to ignore User-Installed Fonts for the purpose of the Font Matching Algorithm.

Any Installed Font which is not a User-Installed font is a Preinstalled Font. It is likely that all users of a particular version of a particular Operating System will have the same set of Preinstalled Fonts installed. As such, Web content authors targetting these Operating Systems may wish to use these fonts' family names inside font-family properties.

10.4. System Font

The System Font is the font which is used by the system-ui generic font family name. It is an example of a Preinstalled Font.

11. Object Model

The contents of @font-face and @font-feature-values rules can be accessed via the following extensions to the CSS Object Model.

11.1. The CSSFontFaceRule interface

The CSSFontFaceRule interface represents a <@font-face> rule.

[Exposed=Window]
interface CSSFontFaceRule : CSSRule {
    readonly attribute CSSStyleDeclaration style;
};

The DOM Level 2 Style specification [DOM-LEVEL-2-STYLE] defined a different variant of this rule. This definition supercedes that one.

11.2. The CSSFontFeatureValuesRule interface

The CSSRule interface is extended as follows:

partial interface CSSRule {  const unsigned short FONT_FEATURE_VALUES_RULE = 14;
}

The CSSFontFeatureValuesRule interface represents a @font-feature-values rule.

interface CSSFontFeatureValuesRule : CSSRule {  attribute CSSOMString fontFamily;
  readonly attribute CSSFontFeatureValuesMap annotation;
  readonly attribute CSSFontFeatureValuesMap ornaments;
  readonly attribute CSSFontFeatureValuesMap stylistic;
  readonly attribute CSSFontFeatureValuesMap swash;
  readonly attribute CSSFontFeatureValuesMap characterVariant;
  readonly attribute CSSFontFeatureValuesMap styleset;
}

[MapClass(CSSOMString, sequence<unsigned long>)]
interface CSSFontFeatureValuesMap {
  void set(CSSOMString featureValueName,
           (unsigned long or sequence<unsigned long>) values);
}

fontFamily of type CSSOMString

The list of one or more font families for which a given set of feature values is defined.

value maps of type CSSFontFeatureValuesMap, readonly

Maps of feature values associated with feature value names for a given font-variant-alternates value type

Each value map attribute of CSSFontFeatureValuesRule reflects the values defined via a corresponding feature value block. Thus, the annotation attribute contains the values contained within a @annotation feature value block, the ornaments attribute contains the values contained with a @ornaments feature value block and so forth.

The CSSFontFeatureValuesMap interface uses the default map class methods but the set method has different behavior. It takes a sequence of unsigned integers and associates it with a given featureValueName. The method behaves the same as the default map class method except that a single unsigned long value is treated as a sequence of a single value. The method throws an exception if an invalid number of values is passed in. If the associated feature value block only allows a limited number of values, the set method throws an InvalidAccessError exception when the input sequence to set contains more than the limited number of values. See the description of multi-valued feature value definitions for details on the maximum number of values allowed for a given type of feature value block. The get method always returns a sequence of values, even if the sequence only contains a single value.

11.3. The CSSFontPaletteValuesRule interface

partial interface CSSRule {
  const unsigned short FONT_PALETTE_VALUES_RULE = 15;
}

interface CSSFontPaletteValuesRule : CSSRule {
  maplike<unsigned long, (CSSOMString or CSSOMRGBColor)>;
  attribute CSSOMString fontFamily;
  attribute CSSOMString basePalette;
}

If the value of the setlike functions is a CSSOMString, it is parsed as a solid color (e.g. using the rgb() syntax). If it refers to anything other than a solid color, the call is ignored or returns undefined.

The fontFamily and basePalette interfaces are parsed according to the appropriate CSS property syntax.

Appendix A: Mapping platform font properties to CSS properties

Import from level 3

12. Acknowledgments

The CSS Working group would like to thank:

Peter Constable for assorted language fixes.

Optical sizing image prepared by Nick Sherman.

Special thanks to Tab Atkins Jr. for providing the text for the section on Font Rendering Controls as well as the section on the font-display descriptor. Special thanks to Ilya Grigorik and David Kuettel for their help in developing these sections.