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

GitHub Issues are preferred for discussion of this specification. When filing an issue, please put the text “css-fonts” in the title, preferably like this: “[css-fonts] …summary of comment… ”. All issues and comments are archived , and there is also a historical archive .

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

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

“At-risk” is a W3C Process term-of-art, and does not necessarily imply that the feature is in danger of being dropped or delayed. It means that the WG believes the feature may have difficulty being interoperably implemented in a timely manner, and marking it as such allows the WG to drop the feature if necessary when transitioning to the Proposed Rec stage, without having to publish a new Candidate Rec without the feature first.

The following features are at-risk, and may be dropped during the CR period:

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 initial stages of specification and implementation. Please comment on any bugs in this spec at https://github.com/w3c/csswg-drafts/issues.

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.

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

Component values are a comma-separated list indicating alternatives. A user agent iterates through the list of family names until it matches an available font that contains a glyph for the character to be rendered. (See §5.3 Cluster matching.) This allows for differences in available fonts across platforms and for differences in the range of characters supported by individual fonts.

body { font-family: Helvetica, Verdana, sans-serif; } If Helvetica is available, it will be used when rendering. If neither Helvetica nor Verdana is present, then the generic font-family sans-serif font will be used.

There are two types of font family names:

<family-name> The name of a font family, such as Helvetica or Verdana in the previous example. <generic-family> Each <generic-family> keyword represents a generic font choice, and behaves as an alias for one or more locally-installed fonts belonging to the specified generic font category. A <generic-family> can thus be used as a reliable fallback for when an author’s more specific font choices are not available. Authors are encouraged to append a generic font family as a last alternative for improved robustness. Note that <generic-family> keywords cannot be quoted (otherwise they are interpreted as a <family-name>). The following generic family keywords are defined: serif, sans-serif, cursive, fantasy, monospace, system-ui, emoji, math and fangsong. See §2.1.3 Generic font families.

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

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

font-family: Red/Black, sans-serif; font-family: "Lucida" Grande, sans-serif; font-family: Ahem!, sans-serif; font-family: test@foo, sans-serif; font-family: #POUND, sans-serif; font-family: Hawaii 5-0, sans-serif; To illustrate this, the following declarations are invalid:

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

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

font-family: "sans-serif", sans-serif; font-family: "default, sans-serif; font-family: "initial", sans-serif; font-family: "inherit", sans-serif; To illustrate this, the following unusual font family names are valid because they are quoted:

If a sequence of identifiers is given as a <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"> Quoting font families prevents escaping mistakes.

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

2.1.2. Relationship Between Faces and Families

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

Family and individual face names For example, given the availability of the fonts below, Futura would match but Futura Medium would not:

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

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

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

2.1.3. Generic font families

Each generic font family must always map to at least one matched font face. However, a single generic font family may be a composite face combining different typefaces based on such things as the Unicode range of the character, the content language of the containing element, user preferences, system settings, etc. Different generic font families may map to the same used font.

User agents should provide reasonable default choices for the generic font families, that express the characteristics of each family as well as possible, within the limits allowed by the underlying technology. User agents are encouraged to allow users to select alternative faces for the generic font families.

serif Serif fonts represent 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. This is due to its typographic role, rather than its design style. Any font that fits this typographic role may be used to represent the generic serif family. Sample serif fonts sans-serif Glyphs in sans-serif fonts, as the term is used in CSS, 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 fits this typographic role may be used to represent the generic sans-serif family. Sample sans-serif fonts 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. For example, Kaiti (Chinese), which uses a brush-based style, would be classified as a CSS cursive font family. CSS uses the term "cursive" to apply to a font for any script, although other names such as Chancery, Brush, Swing and Script are also used in font names. Sample cursive fonts fantasy Fantasy fonts are primarily decorative 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. Sample fantasy fonts monospace The sole criterion of a monospace font is that all glyphs have the same fixed width. This is often used to render samples of computer code. Sample monospace fonts system-ui This generic font family lets 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 the native OS. <div id="system-text" style="font-family: system-ui"></div> ... window.getComputedStyle(document.getElementById("system-text")).getPropertyValue("font-family"); As with other generic font families, the substitution of specific installed fonts for system-ui does not affect the computed style. The script above should not have any knowledge of how system-ui is expanded to include a collection of system user interface fonts. In particular, the above script should yield a result of "system-ui" on every platform. emoji This font family is intended for use with emoji characters. Emoji are pictographs (pictorial symbols) that are typically presented in a colorful form and used inline in text. They represent things such as faces, weather, vehicles and buildings, food and drink, animals and plants, or icons that represent emotions, feelings, or activities. math This font family is intended for use with mathematical expressions. Such fonts may include additional data (for example, the OpenType MATH table) to help with the hierarchical process of equation layout. In particular, they may contain stylistic and stretching glyph variants useful in setting mathematical equations. fangsong This font family is used for Fang Song (仿宋) typefaces in Chinese. Fang Song is a relaxed, intermediate form between Song (serif) and Kai (cursive). Typically, the horizontal lines are tilted, the endpoint flourishes are smaller, and there is less variation in stroke width, compared to a Song style. Fang Song is often used for official Chinese Government documents.

2.1.4. Standard font families

Standard font families are font families which are expected to be interoperable between browsers, but which may not exist on every platform or operating system. They are not required to map to a concrete font face. Just like generic font families, standard font families may be a composite face combining different typefaces based on such things as the Unicode range of the character, the content language of the containing element, user preferences, system settings, etc.

Note: These standard font families are expected to exist on different platforms, but be backed by different fonts. However, some CSS authors might prefer to handle this kind of platform-specific fallback themselves using the font-family property. Therefore, user agents are encouraged to also expose these standard font families by other, platform-specific, font-family names, in addition to the standard names given here. Authors can use these additional names to control font fallback themselves between different platforms.

ui-serif This font family is used for the serif variant of the system’s user interface. The purpose of ui-serif is to allow web content to integrate with the look and feel of the native OS. Sample ui-serif font on macOS Catalina and iOS 13: New York ui-sans-serif This font family is used for the sans-serif variant of the system’s user interface. The purpose of ui-sans-serif is to allow web content to integrate with the look and feel of the native OS. ui-monospace This font family is used for the monospaced variant of the system’s user interface. The purpose of ui-monospace is to allow web content to integrate with the look and feel of the native OS. Sample ui-monospace font on macOS Catalina and iOS 13: SF Mono ui-rounded This font family is used for the rounded variant of the system’s user interface. The purpose of ui-rounded is to allow web content to integrate with the look and feel of the native OS. Sample ui-rounded font on macOS Catalina and iOS 13: SF Rounded

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:

Values have the following meanings:

<number> Each number indicates a weight that is at least as dark as its predecessor. Only values greater than or equal to 1, and less than or equal to 1000, are valid, and all other values are invalid. Numeric values typically correspond to the commonly used weight names below. 100 - Thin

200 - Extra Light (Ultra Light)

300 - Light

400 - Normal

500 - Medium

600 - Semi Bold (Demi Bold)

700 - Bold

800 - Extra Bold (Ultra Bold)

900 - Black (Heavy) Note: A font might internally provide its own weight name mappings, but those mappings within the font are disregarded in CSS. normal Same as 400 . bold Same as 700 . bolder Specifies a bolder weight than the inherited value. See §2.2.1 Relative Weights. lighter Specifies a lighter weight than the inherited value. See §2.2.1 Relative Weights.

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

2.2.1. Relative Weights

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

Inherited value ( w ) bolder lighter w < 100 400 No change 100 ≤ w < 350 400 100 350 ≤ w < 550 700 100 550 ≤ w < 750 900 400 750 ≤ w < 900 900 700 900 ≤ w No change 700

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

2.2.2. Missing weights

Quite often there are only a few weights available for a particular font family. When a weight is specified for which no face exists, a face with a nearby weight is used. In general, bold weights map to faces with heavier weights and light weights map to faces with lighter weights. (See the §5 Font Matching Algorithm for a precise definition.)

Weight mappings for a font family with 400, 700 and 900 weight faces Weight mappings for a font family with 300 and 600 weight faces The examples here illustrate which face is used for different weights. Grey indicates that a face for the desired weight does not exist, so a face with a nearby weight is used.

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

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

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

Absolute keyword value Numeric value ultra-condensed 50% extra-condensed 62.5% condensed 75% semi-condensed 87.5% normal 100% semi-expanded 112.5% expanded 125% extra-expanded 150% ultra-expanded 200%

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

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

Width mappings for a font family with condensed, normal and expanded width faces The figure below shows how nine font-stretch property settings affect font matching for a font family containing a variety of discrete widths. Grey indicates a width for which no face exists and a different width is substituted:

User Agents must not synthesize stretched faces for font families which lack actual stretched faces.

For compatibility with [CSS-FONTS-3], getComputedStyle() serializes values that correspond to one of the font-stretch keywords as that keyword (instead of as a <percentage>).

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.

Artificial sloping versus real italics Compare the artificially sloped renderings of Palatino "a" and Baskerville "N" in grey with the actual italic versions:

Values have the following meanings:

normal Matches against a face that is classified as a normal face, one that is neither italic or obliqued. This represents an oblique value of "0". italic Matches against a font that is labeled as an italic face, or an oblique face if one does not exist. oblique <angle>? Controls matching against an oblique face. Positive angles represent a clockwise slant; negative angles represent a counter-clockwise slant. The lack of an <angle> represents 14deg . (Note that a font might internally provide its own mapping for "oblique", but the mapping within the font is disregarded.) Fractional and negative values are accepted; however, values less than -90deg or values greater than 90deg are invalid. If no oblique faces exist, this value can match an italic face.

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

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

The threshold for preferring oblique over normal should be lower than the average angle.

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

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

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

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

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

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

This property indicates the desired height of glyphs from the font. For scalable fonts, the font-size is a scale factor applied to the EM unit of the font. For non-scalable fonts, the font-size is converted into absolute units and matched against the declared font-size of the font, using the same absolute coordinate space for both of the matched values.

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

Values have the following meanings:

<absolute-size> An <absolute-size> keyword refers to an entry in a table of font sizes computed and kept by the user agent. See §2.5.1 Absolute Size Keyword Mapping Table. Possible values are: [ xx-small | x-small | small | medium | large | x-large | xx-large | xxx-large ] <relative-size> A <relative-size> keyword is interpreted relative to the computed font-size of the parent element and possibly the table of font sizes. Possible values are: [ larger | smaller ] If the parent element has a keyword font size in the absolute size keyword mapping table, larger may compute the font size to the next entry in the table, and smaller may compute the font size to the previous entry in the table. For example, if the parent element has a font size of medium, specifying a value of larger may make the font size of the child element large. Instead of using next and previous items in the previous keyword table, User Agents may instead use a simple ratio to increase or decrease the font size relative to the parent element. The specific ratio is unspecified, but should be around 1.2–1.5. This ratio may vary across different elements. Note: A sight-impaired user may request a User Agent use a higher ratio than default, in order to aid readability. In addition, a User Agent may choose to use different ratios when it detects paragraph text as opposed to title text. <length-percentage> A length value specifies an absolute font size (independent of the user agent’s font table). Negative lengths are invalid. A percentage value specifies an absolute font size relative to the parent element’s computed font-size. Negative percentages are invalid. Note: Use of percentage values or font-relative lengths such as ems and rems leads to more robust and cascadable style sheets.

p { font-size: 12pt; } blockquote { font-size: larger } em { font-size: 150% } em { font-size: 1.5em } The following style sheet demonstrates various ways of specifying the font size.

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

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

font-size: clamp(10px, ..., 36px); font-size can be clamped, for responsive typography.

2.5.1. Absolute Size Keyword Mapping Table

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

CSS absolute-size values xx-small x-small small medium large x-large xx-large xxx-large scaling factor 3/5 3/4 8/9 1 6/5 3/2 2/1 3/1 HTML headings h6 h5 h4 h3 h2 h1 HTML font sizes 1 2 3 4 5 6 7

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

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

For any given font size, the apparent size and effective 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 and 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 be less readable. The font-size-adjust property is a way to preserve the readability of text when font fallback occurs. It does this by adjusting the font-size so that the x-height is the same regardless of the font used.

p { font-family: Verdana, Futura, Times; } <p>Lorem ipsum dolor sit amet, ...</p> The style defined below defines Verdana as the desired font family, but if Verdana is not available Futura or Times will be used. Verdana has a relatively high aspect value, lowercase letters are relatively tall compared to uppercase letters, so at small sizes text appears legible. Times has a lower aspect value and so if fallback occurs, the text will be less legible at small sizes than Verdana.

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.

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

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

none Do not preserve the font’s x-height. <number> Specifies the aspect value used in the calculation below to calculate the adjusted font size: c = ( a / a' ) s where: s = font-size value a = aspect value as specified by the 'font-size-adjust' property a' = aspect value of actual font c = adjusted font-size to use Negative values are invalid. This value applies to any font that is selected but in typical usage it should be based on the aspect value of the first font in the font-family list. If this is specified accurately, the (a/a') term in the formula above is effectively 1 for the first font and no adjustment occurs. If the value is specified inaccurately, text rendered using the first font in the family list will display differently in older user agents that don’t support font-size-adjust.

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

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

replace with an example of actually using font-size-adjust rather than how to measure it <https://github.com/w3c/csswg-drafts/issues/2859>

font-size-adjust value is accurate for the given font. 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 thevalue is accurate for the given font. Two spans with borders are used to determine the aspect value of a font. The font-size is the same for both spans but the font-size-adjust property is specified only for the right span. Starting with a value of 0.5, the aspect value can be adjusted until the borders around the two letters line up. p { font-family: Futura; font-size: 500px; } span { border: solid 1px red; } .adjust { font-size-adjust: 0.5; } <p><span>b</span><span class="adjust">b</span></p> Futura with an aspect value of 0.5 The box on the right is a bit bigger than the one on the left, so the aspect value of this font is something less than 0.5. Adjust the value until the boxes align.

2.7. 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 CSS Fonts Levels 3 or 4 can be used in the font shorthand:

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:

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; } In the second rule, the font size percentage value ("80%") refers to the computed font-size of the parent element. In the third rule, the line height percentage ("110%") refers to the font size of the element itself. The first three rules do not specify the font-variant and font-weight explicitly, so these properties receive their initial values (normal). Notice that the font family name "new century schoolbook", which contains spaces, is enclosed in quotes. The fourth rule sets the font-weight to bold, the font-style to italic, and implicitly sets font-variant to normal. The fifth rule sets the font-variant (small-caps), the font-size (120% of the parent’s font size), the line-height (120% of the font size) and the font-family (fantasy). It follows that the keyword normal applies to the two remaining properties: font-style and font-weight. The sixth rule sets the font-style, font-stretch, font-size, and font-family, the other font properties being set to their initial values. The seventh rule sets font-style to oblique 25deg, font-weight to 753, and font-stretch to condensed. Note that the 25deg in this rule must be immediately following the "oblique" keyword.

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 } If the font used for dropdown menus on a particular system happened to be, for example, 9-point Charcoal, with a weight of 600, then P elements that were descendants of BUTTON would be displayed as if this rule were in effect: button p { font: 600 9pt Charcoal } Because the font shorthand resets to its initial value any property not explicitly given a value, this has the same effect as this declaration: button p { font-style: normal; font-variant: normal; font-weight: 600; font-size: 9pt; line-height: normal; font-family: Charcoal }

2.8. Controlling synthetic faces

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

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

auto Synthesis of bold faces is allowed none Synthesis of bold faces is not allowed

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

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

auto Synthesis of oblique faces is allowed none Synthesis of oblique faces is not allowed

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

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

auto Synthesis of small caps faces is allowed none Synthesis of small caps faces is not allowed

2.8.4. Controlling synthetic faces: the font-synthesis shorthand

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

font-synthesis value font-synthesis-weight value font-synthesis-style value none none none weight auto none style none auto weight style auto auto

*:lang(ar) { font-synthesis: none; } The style rule below disables the use of synthetically obliqued Arabic:

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:

Browser Timeout Fallback Swap Chrome 35+ 3 seconds yes yes Opera 3 seconds yes yes Firefox 3 seconds yes yes Internet Explorer 0 seconds yes yes Safari 3 seconds yes yes

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

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

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

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

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

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

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

Define custom timeout values for each font.

Define custom display and timeout policies per element.

3.2. The Font Display Timeline

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

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

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

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

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

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

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

4. Font Resources

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:

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; } To use a downloadable font called Gentium: The user agent will download Gentium and use it when rendering text within paragraph elements. If for some reason the site serving the font is unavailable, the default serif font will be used.

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.

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

Name: src For: @font-face Value: see prose Initial: N/A

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 parse and activate. Parsing this descriptor is more complicated than parsing other descriptors; see §4.3.1 Parsing the src descriptor for the parsing rules. 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.

4.3.1. Parsing the src descriptor

The value of the src descriptor is parsed piecewise.

First, opening and closing parentheses are matched. If these parentheses cannot be matched, the value is a parse error. Matching the parentheses has the effect of partitioning the value into multiple regions, each of which is either inside outermost parentheses or outside outermost parentheses.

Once the value is partitioned, all the commas outside outermost parentheses are located. The value is then split at these comma locations.

Each item in the split value is then parsed against this grammar:

If parsing a particular item in the split value results in a parse error, that item is thrown out.

Define what "thrown out" means

If no item in the split value survives, then the descriptor is a parse error.

These parsing rules allow for graceful fallback of fonts for user agents which don’t support a particular font technology.

4.3.2. Loading an individual item in the src descriptor

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 of SVG fonts, the URL points to an element within a document containing SVG font definitions. If the element reference is omitted, a reference to the first defined font is implied. 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]. Conformant user agents must skip downloading a font resource if the fragment identifier is unknown or unsupported. For example, older user agents which do not support OpenType collections will skip to the next url in the list.

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' */

4.3.3. Selecting items in the src

External references consist of a URL, followed by an optional hint describing the format of the font resource referenced by that URL. Conformant user agents must skip downloading a font resource if the format hint indicates an unsupported or unknown font format, or if any of the font technologies are unsupported by the user agent. If no format hint is supplied, the user agent should download the font resource.

@font-face { font-family: bodytext; src: url(ideal-sans-serif.woff) format("woff"), url(basic-sans-serif.ttf) format("opentype"); } For example, the following shows how to load a WOFF font if possible, otherwise use an OpenType font

Format strings defined by this specification are as follows. The <font-format> values are synonyms for the formats below.

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

The features requirement refers to support for font features, commonly implemented in [OPENTYPE] with the GSUB and the GPOS tables, as well as in [AAT-FEATURES] using the morx table. The section on §6 Font Feature Properties describes properties that interact with these facilities.

The variations requirement refers to the support of font variations, commonly implemented in [OPENTYPE] with the avar , cvar , fvar , gvar , HVAR , MVAR , STAT , and VVAR tables, as well as in [AAT-FEATURES] using the avar , cvar , fvar , and gvar tables. The section on §2 Basic Font Properties as well as the section on §8 Font Variation Properties describe properties that interact with these facilities.

The color requirement lists various types of color font file technologies. Each of the arguments to the color function represents a table inside [OPENTYPE] or [AAT-FEATURES] fonts which must be supported to satisfy this requirement.

The palettes requirement refers to support for font palettes, commonly implemented in the [OPENTYPE] and [AAT-FEATURES] with the CPAL table. The section on §9 Color Font Support describes properties that interact with these facilities.

Web authors can specify the format function to indicate that 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.

@font-face { font-family: "Trickster"; src: url("trickster-COLR.otf") format(opentype supports color(COLR)), url("trickster-outline.otf") format(opentype); } This @font-face block shows how to use a color font if support is present on the user agent, and falls back to a non-color-font if support is not present.

4.3.3.3. Local font fallback

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), /* prefer 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 an @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 must be 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.

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

Note: 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"); } Use a local font or reference an SVG font in another document: Create an alias for local Japanese fonts on different platforms: @font-face { font-family: jpgothic; src: local(HiraKakuPro-W3), local(Meiryo), local(IPAPGothic); } Reference a font face that cannot be matched within a larger family: @font-face { font-family: Hoefler Text Ornaments; /* has the same font properties as Hoefler Text Regular */ src: local(HoeflerText-Ornaments); } Since localized fullnames never match, a document with the header style rules below would always render using the default serif font, regardless whether a particular system locale parameter is set to Finnish or not: @font-face { font-family: SectionHeader; src: local("Arial Lihavoitu"); /* Finnish fullname for Arial Bold, should fail */ font-weight: bold; } h2 { font-family: SectionHeader, serif; } A conformant user agent would never load the font 'gentium.eot' in the example below, since it is included in the first definition of the src descriptor which is overridden by the second definition in the same @font-face rule: @font-face { font-family: MainText; src: url(gentium.eot); /* for use with older user agents */ src: local("Gentium"), url(gentium.woff); /* Overrides src definition */ }

Name: font-style For: @font-face Value: auto | normal | italic | oblique [ <angle> | <angle> <angle> ]? Initial: auto

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 auto values for these three descriptors have the following effects:

For font selection purposes, the font is selected as if the appropriate initial value is chosen

For variation axis clamping, clamping does not occur

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.

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

The BBC provides news services in a wide variety of languages, many that are not well supported across all platforms. Using an @font-face rule, the BBC could provide a font for any of these languages, as it already does via a manual font download. @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; } Technical documents often require a wide range of symbols. The STIX Fonts project is one project aimed at providing fonts to support a wide range of technical typesetting in a standardized way. The example below shows the use of a font that provides glyphs for many of the mathematical and technical symbol ranges within Unicode:

@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; } This example shows how an author can override the glyphs used for Latin characters in a Japanese font with glyphs from a different font. The first rule specifies no range so it defaults to the entire range. The range specified in the second rule overlaps but takes precedence because it is defined later.

/* 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; } Consider a family constructed to optimize bandwidth by separating out Latin, Japanese and other characters into different font files: For simple Latin text, only the font for Latin characters is downloaded: body { font-family: DroidSans; } <p>This is that</p> In this case the user agent first checks the unicode-range for the font containing Latin characters (DroidSans.woff). Since all the characters above are in the range U+0-5FF, the user agent downloads the font and renders the text with that font. Next, consider text that makes use of an arrow character (⇨): <p>This ⇨ that<p> The user agent again first checks the unicode-range of the font containing Latin characters. Since U+2000-2300 includes the arrow code point (U+21E8), the user agent downloads the font. For this character however the Latin font does not have a matching glyph, so the effective unicode-range used for font matching excludes this code point. Next, the user agent evaluates the Japanese font. The unicode-range for the Japanese font, U+3000-9FFF and U+ff??, does not include U+21E8, so the user agent does not download the Japanese font. Next the fallback font is considered. The @font-face rule for the fallback font does not define unicode-range so its value defaults to the range of all Unicode code points. The fallback font is downloaded and used to render the arrow character.

4.6. Font features and variations: the 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-feature-settings and font-variation-settings properties defined below except that the CSS-wide keywords are omitted. When multiple font feature descriptors, properties, or variations are used, optionally along with a named instance, the cumulative effect on text rendering is detailed in the section §7 Font Feature and Variation Resolution below.

These descriptors set features and variation values on the font object which the @font-face rule represents, rather than on an entire element. Therefore, when using these descriptors, only some glyphs in an element may be rendered with that feature, due to §5.3 Cluster matching.

4.7. Using named instances from variable fonts: the font-named-instance descriptor

If the font-named-instance descriptor is set to a value other than auto, then the appropriate stage in the §7 Font Feature and Variation Resolution will inspect the font file to find the first named instance in the font which has a localized name equal to the given string according to the rules given in §5.1 Localized name matching. If no such named instance exists, this descriptor is treated as if it has a value of auto. Otherwise, this named instance’s variation axis values are applied to this position in the §7 Font Feature and Variation Resolution.

@font-face { font-family: "AccuroVar"; src: url("accurovar.otf") format("opentype"); font-named-instance: "Grotesque"; font-variation-settings: "XHGT" 0.7; } For example, the following @font-face block will apply the instance named "Grotesque" but will override the "XHGT" axis to have a value of 0.7.

Note: Because the variation axis values supplied in the font-weight, font-stretch, and font-style properties are applied before the value in the font-named-instance descriptor, there is no need to change the value of those properties when a named instance is desired.

4.8. Font request guidelines

4.8.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 must render text according to the font-display descriptor of that @font-face block. In cases where the font download fails, user agents must display the text visibly. 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.8.2. Font fetching requirements

For font loads, user agents must use the potentially CORS-enabled fetch method defined by the [HTML] 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.

https://example.com/page.html and all URL’s link to valid font resources supported by the user agent. For the examples given below, assume that a document is located atand all URL’s link to valid font resources supported by the user agent. Fonts defined with the src descriptor values below will be loaded: /* 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); Fonts defined with the src descriptor values below will fail to load: /* 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.9. 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.

Name: font-display For: @font-face Value: auto | block | swap | fallback | optional Initial: auto

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

Name: font-display For: @font-feature-values Value: auto | block | swap | fallback | optional Initial: auto

4.10. 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 §7 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. Localized name matching

Some font file formats allow font faces to carry multiple localizations of a particular string (e.g. family name or named instance). User agents must recognize and correctly match all of these names independent of the underlying platform localization, system API used, or document encoding.

Localized family names For example, for each of the fonts listed below, the author can use either the Latin name or the localized name in the font-family property, and the results will be identical on all systems:

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.

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

When text contains characters such as combining marks, ideally the base character should be rendered using the same font as the mark, this assures proper placement of the mark. For this reason, the font matching algorithm for clusters is more specialized than the general case of matching a single character by itself. For sequences containing variation selectors, which indicate the precise glyph to be used for a given character, user agents always attempt system font fallback to find the appropriate glyph before using the default glyph of the base character.

A sequence of codepoints containing combining mark or other modifiers is termed a grapheme cluster (see [CSS3TEXT] and [UAX29] for a more complete description). For a given cluster containing a base character, b and a sequence of combining characters c1, c2…, the entire cluster is matched using these steps:

For each family in the font list, a face is chosen using the style selection rules defined in the previous section. If all characters in the sequence b + c1 + c2 … are completely supported by the font, select this font for the sequence. If a sequence of multiple codepoints is canonically equivalent to a single character and the font supports that character, select this font for the sequence and use the glyph associated with the canonically equivalent character for the entire cluster. If no font was found in the font list in step 1: If c1 is a variation selector, system fallback must be used to find a font that supports the full sequence of b + c1. If no font on the system supports the full sequence, match the single character b using the normal procedure for matching single characters and ignore the variation selector. Note: a sequence with more than one variation selector must be treated as an encoding error and the trailing selectors must be ignored. [UNICODE] Otherwise, the user agent may optionally use system font fallback to match a font that supports the entire cluster. If no font is found in step 2, use the matching sequence from step 1 to determine the longest sequence that is completely supported by a font in the font list and attempt to match the remaining combining characters separately using the rules for single characters.

5.4. Character handling issues

CSS font matching is always performed on text runs containing Unicode characters [UNICODE], so documents using legacy encodings are assumed to have been transcoded before matching fonts. For fonts containing character maps for both legacy encodings and Unicode, the contents of the legacy encoding character map must have no effect on the results of the font matching process.

The font matching process does not assume that text runs are in either normalized or denormalized form (see [CHARMOD-NORM] for more details). Fonts may only support precomposed forms and not the decomposed sequence of base character plus combining marks. Authors should always tailor their choice of fonts to their content, including whether that content contains normalized or denormalized character streams.

If a given character is a Private-Use Area Unicode codepoint, user agents must only match font families named in the font-family list that are not generic families. If none of the families named in the font-family list contain a glyph for that codepoint, user agents must display some form of missing glyph symbol for that character rather than attempting system font fallback for that codepoint. When matching the replacement character U+FFFD, user agents may skip the font matching process and immediately display some form of missing glyph symbol, they are not required to display the glyph from the font that would be selected by the font matching process.

In general, the fonts for a given family will all have the same or similar character maps. The process outlined here is designed to handle even font families containing faces with widely variant character maps. However, authors are cautioned that the use of such families can lead to unexpected results.

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. It now functions as a shorthand for a set of properties that provide control over stylistic font features.

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. If a writing system has been explicitly specified, it must take precedence over the customary one implied by the content language.

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.

Kerning is the contextual adjustment of inter-glyph spacing. This property controls metric kerning, kerning that utilizes adjustment data contained in the font.

auto Specifies that kerning is applied at the discretion of the user agent normal Specifies that kerning is applied none Specifies that kerning is not applied

For fonts that do not include kerning data this property will have no visible effect. When rendering with OpenType fonts, the [OPENTYPE] specification suggests that kerning be enabled by default. When kerning is enabled, the OpenType kern feature is enabled (for vertical text runs the vkrn feature is enabled instead). User agents must also support fonts that only support kerning via data contained in a kern font table, as detailed in the OpenType specification. If the letter-spacing property is defined, kerning adjustments are considered part of the default spacing and letter spacing adjustments are made after kerning has been applied.

When set to auto, user agents can determine whether to apply kerning or not based on a number of factors: text size, script, or other factors that influence text processing speed. Authors who want proper kerning should use normal to explicitly enable kerning. Likewise, some authors may prefer to disable kerning in situations where performance is more important than precise appearance. However, in well-designed modern implementations the use of kerning generally does not have a large impact on text rendering speed.

Ligatures and contextual forms are ways of combining glyphs to produce more harmonized forms.

Individual values have the following meanings:

normal A value of normal as described in detail in the next section. For OpenType fonts, common ligatures and contextual forms are on by default, discretionary and historical ligatures are not. none Specifies that all types of ligatures and contextual forms covered by this property are explicitly disabled. In situations where ligatures are not considered necessary, this may improve the speed of text rendering. common-ligatures Enables display of common ligatures (OpenType features: liga, clig ). For OpenType fonts, common ligatures are enabled by default. no-common-ligatures Disables display of common ligatures (OpenType features: liga, clig ). discretionary-ligatures Enables display of discretionary ligatures (OpenType feature: dlig ). Which ligatures are discretionary or optional is decided by the type designer, so authors will need to refer to the documentation of a given font to understand which ligatures are considered discretionary. no-discretionary-ligatures Disables display of discretionary ligatures (OpenType feature: dlig ). historical-ligatures Enables display of historical ligatures (OpenType feature: hlig ). no-historical-ligatures Disables display of historical ligatures (OpenType feature: hlig ). contextual Enables display of contextual alternates (OpenType feature: calt ). Although not strictly a ligature feature, like ligatures this feature is commonly used to harmonize the shapes of glyphs with the surrounding context. For OpenType fonts, this feature is on by default. no-contextual Disables display of contextual alternates (OpenType feature: calt ).

Required ligatures, needed for correctly rendering complex scripts, are not affected by the settings above, including none (OpenType feature: rlig).

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

This property is used to enable typographic subscript and superscript glyphs. These are alternate glyphs designed within the same em-box as default glyphs and are intended to be laid out on the same baseline as the default glyphs, with no resizing or repositioning of the baseline. They are explicitly designed to match the surrounding text and to be more readable without affecting the line height.

Individual values have the following meanings:

normal None of the features listed below are enabled. sub Enables display of subscript variants (OpenType feature: subs ). super Enables display of superscript variants (OpenType feature: sups ).

Because of the semantic nature of subscripts and superscripts, when the value is either sub or super for a given contiguous run of text, if a variant glyph is not available for all the characters in the run, simulated glyphs should be synthesized for all characters using reduced forms of the glyphs that would be used without this feature applied. This is done per run to avoid a mixture of variant glyphs and synthesized ones that would not align correctly. In the case of OpenType fonts that lack subscript or superscript glyphs for a given character, user agents must synthesize appropriate subscript and superscript glyphs.

In situations where text decorations are only applied to runs of text containing superscript or subscript glyphs, the synthesized glyphs may be used, to avoid problems with the placement of decorations.

In the past, user agents have used font-size and vertical-align to simulate subscripts and superscripts for the sub and sup elements. To allow a backwards compatible way of defining subscripts and superscripts, it is recommended that authors use conditional rules [CSS3-CONDITIONAL] so that older user agents will still render subscripts and superscripts via the older mechanism.

Because font-size: smaller is often used for these elements, the effect