CSS Fonts Module Level 4

Editor’s Draft,

This version:
https://drafts.csswg.org/css-fonts-4/
Issue Tracking:
Inline In Spec
GitHub Issues
Editors:
John Daggett (Invited Expert)
(Apple Inc.)

Abstract

This specification defines modifications to the existing CSS Fonts 3 specification along with additional experimental features.

CSS is a language for describing the rendering of structured documents (such as HTML and XML) on screen, on paper, in speech, etc.

Status of this document

This is a public copy of the editors’ draft. It is provided for discussion only and may change at any moment. Its publication here does not imply endorsement of its contents by W3C. Don’t cite this document other than as work in progress.

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.

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

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

This document is governed by the 1 September 2015 W3C Process Document.

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

1. Introduction

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

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

2. Basic Font Properties

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

2.1. Font family: the font-family property

Import from level 3

2.2. Font weight: the font-weight property

Name: font-weight
Value: normal | bold | bolder | lighter | <number>
Initial: normal
Applies to: all elements
Inherited: yes
Percentages: n/a
Media: visual
Computed value: numeric weight value (see description)
Canonical order: per grammar
Animation type: discrete

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

Values have the following meanings:

<number>
These values form an ordered sequence, where each number indicates a weight that is at least as dark as its predecessor. Only values between 1 - 999 are valid, and all other values are treated as parse errors. Certain numeric values correspond to the commonly used weight names below (Note that a font may internally provide its own mappings, but those mappings within the font are disregarded):
  • 100 - Thin
  • 200 - Extra Light (Ultra Light)
  • 300 - Light
  • 400 - Normal
  • 500 - Medium
  • 600 - Semi Bold (Demi Bold)
  • 700 - Bold
  • 800 - Extra Bold (Ultra Bold)
  • 900 - Black (Heavy)
normal
Same as 400.
bold
Same as 700.
bolder
Specifies a bolder weight than the inherited value.
lighter
Specifies a lighter weight than the inherited value.

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

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

weight mappings for a family with 400, 700 and 900 weights

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

weight mappings for a family with 300, 600 weights

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

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

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

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

Inherited value bolder lighter
- 99 400 No change
100 - 349 400 100
350 - 549 700 100
550 - 749 900 400
750 - 899 900 700
900 - No change 700

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

2.3. Font width: the font-stretch property

Name: font-stretch
Value: normal | ultra-condensed | extra-condensed | condensed | semi-condensed | semi-expanded | expanded | extra-expanded | ultra-expanded | <percentage>
Initial: normal
Applies to: all elements
Inherited: yes
Percentages: Not resolved.
Media: visual
Computed value: numeric weight value (see description)
Canonical order: per grammar
Animatable: As <number>

The font-stretch property selects a normal, condensed, or expanded face from a font family. Absolute keyword values are aliased to have the following meaning (Note that a font may internally provide its own mappings, but those mappings within the font are disregarded):

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%

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

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

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

2.4. Font style: the font-style property

Name: font-style
Value: normal | italic | oblique <angle>?
Initial: normal
Applies to: all elements
Inherited: yes
Percentages: n/a
Media: visual
Computed value: As specified
Canonical order: per grammar
Animatable: If both "from" and "to" values are "oblique", then yes, as an <angle>. Otherwise, no.

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

artificial sloping vs. real italics

Artificial sloping versus real italics

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 oblique face, or an italic face if one is not.
oblique <angle>?
Controls matching against an oblique face. The lack of a number represents an angle of "20deg". Values less than or equal to -90deg or values greater than or equal to 90deg are invalid and are treated as parse errors. (Note that a font may internally provide its own mapping for "oblique", but that mapping within the font is disregarded)

Some font families may contain only zero or one italic or oblique face, while yet other families may contain multiple oblique faces with varying angles. The font matching routine will select a font to use which is closest to the requested angle. In general, for a requested angle greater or equal to 20deg, larger angles are prefered; otherwise, smaller angles are preferred (see the font matching section below for the precise algorithm). Fractional and negative values are accepted, but values less than or equal to -90 as well as values greater than or equal to 90 are not allowed and are treated as parse errors. For TrueType / OpenType fonts which use variations, the "slnt" variation is used to implement oblique values, and the "ital" variation with a value of "1" is used to implement the italic values. The meaning of a negative value for "oblique" is to slope the text in the opposite direction. If no italic or oblique face is available, oblique faces can be synthesized by rendering non-obliqued faces with an artificial obliquing operation. The use of these artificially obliqued faces can be disabled using the font-synthesis property. The details of the obliquing operation are not explicitly defined.

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

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

2.5. Font size: the font-size property

Name: font-size
Value: <absolute-size> | <relative-size> | <length-percentage>
Initial: medium
Applies to: all elements
Inherited: yes
Percentages: refer to parent element’s font size
Media: visual
Computed value: absolute length
Canonical order: per grammar
Animatable: As <length>

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

<absolute-size>
An <absolute-size> keyword refers to an entry in a table of font sizes computed and kept by the user agent. Possible values are:

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

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

[ larger | smaller ]

For example, if the parent element has a font size of medium, a value of larger will make the font size of the current element be large. If the parent element’s size is not close to a table entry, the user agent is free to interpolate between table entries or round off to the closest one. The user agent may have to extrapolate table values if the numerical value goes beyond the keywords.

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

A percentage value specifies an absolute font size relative to the parent element’s font size. Use of percentage values, or values in 'em’s, leads to more robust and cascadable style sheets.

Negative percentages are invalid.

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

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

Note 1. To preserve readability, an UA applying these guidelines should nevertheless avoid creating font-size resulting in less than 9 device pixels per EM unit on a computer display.

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

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

Child elements inherit the computed font-size value (otherwise, the effect of font-size-adjust would compound).

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

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

TODO: Migrate this from level 3.

2.7. Controlling synthetic faces: the font-synthesis property

Name: font-synthesis
Value: none | [ weight || style || small-caps ]
Initial: weight style small-caps
Applies to: all elements
Inherited: yes
Percentages: N/A
Media: visual
Computed value: as specified
Canonical order: per grammar
Animatable: no

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

The style rule below disables the use of synthetically obliqued Arabic:

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

3. Font Resources

3.1. Font reference: the src descriptor

Name: src
For: @font-face
Value: [ <url> [ format( <string> # )]? | <font-face-name> ] #
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 activate. Activation of a font involves downloading the file or reading it from disk, parsing it, and perhaps additional user-agent-dependent steps. Fonts containing invalid data or local font faces that are not found are ignored and the user agent loads the next font in the list.

As with other URLs in CSS, the URL may 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. If a container format lacks a defined fragment identifier scheme, implementations should use a simple 1-based indexing scheme (e.g. "font-collection#1" for the first font, "font-collection#2" for the second font).

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.svg#simple);    /* load SVG font with id 'simple' */

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

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

Format strings defined by this specification:

String Font Format Common extensions
"woff" WOFF (Web Open Font Format) .woff
"truetype" TrueType .ttf
"opentype" OpenType .ttf, .otf
"embedded-opentype" Embedded OpenType .eot
"svg" SVG Font .svg, .svgz
"woff-variations" WOFF (Web Open Font Format) with associated variations support .woff
"truetype-variations" TrueType with associated variations support .ttf
"opentype-variations" OpenType with associated variations support .ttf, .otf

Given the overlap in common usage between TrueType and OpenType, the format hints "truetype" and "opentype" must be considered as synonymous; a format hint of "opentype" does not imply that the font contains Postscript CFF style glyph data or that it contains OpenType layout information (see Appendix A for more background on this).

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

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

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

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

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

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

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

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

Use a local font or reference an SVG font in another document:

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

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

3.2. Font property descriptors: the font-style, font-weight, and font-stretch descriptors

Name: font-style
For: @font-face
Value: normal | italic | oblique [ <angle> | <angle>-<angle> ] ?
Initial: normal
Name: font-weight
For: @font-face
Value: normal | bold | [ <number> | <number>-<number> ]
Initial: normal
Name: font-stretch
For: @font-face
Value: normal | ultra-condensed | extra-condensed | condensed | semi-condensed | semi-expanded | expanded | extra-expanded | ultra-expanded | [ <percentage> | <percentage>-<percentage> ]
Initial: normal

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 may swap the computed value of the startpoint and endpoint of the range in order to forbid decreasing ranges. Both endpoints are inclusive. The ranges are used in the Font Matching Algorithm below.

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

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:

regular face display

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:

synthetic italics display

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:

real italics display

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

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

4.1. Case sensitivity of font family names

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

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 an uppercase A (U+0041) 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.

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.

4.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 may include a given character in the character map but lack the shaping information (e.g. OpenType layout tables or Graphite tables) necessary for correctly rendering text runs containing that character.

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

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

  1. Using the computed font property values for a given element, the user agent starts with the first family name specified by the font-family property.
  2. If the family name is a generic family keyword, the user agent looks up the appropriate font family name to be used. User agents may choose the generic font family to use based on the language of the containing element or the Unicode range of the character.
  3. For other family names, the user agent attempts to find the family name among fonts defined via @font-face rules and then among available system fonts, matching names with a case-insensitive comparison as outlined in the section above. On systems containing fonts with multiple localized font family names, user agents must match any of these names independent of the underlying system locale or platform API used. If the font resources defined for a given face in an @font-face rule are either not available or contain invalid font data, then the face should be treated as not present in the family. If no faces are present for a family defined via @font-face rules, the family should be treated as missing; matching a platform font with the same name must not occur in this case.
  4. If a font family match occurs, the user agent assembles the set of font faces in that family and then narrows the set to a single face using other font properties in the order given below. Fonts may present in this group which can support a range of font-stretch, font-style, or font-weight properties. In this case, the algorithm proceeds as if each supported combination of values are a unique font in the set. If such a font is ultimately selected by this algorithm, particular values for font-stretch, font-style, and font-weight must be applied before any layout or rendering occurs. The application of these values must be applied in the Apply font matching variations step detailed in Font Feature and Variation Resolution. A group of faces defined via @font-face rules with identical font descriptor values but differing unicode-range values are considered to be a single composite face for this step:
    1. font-stretch is tried first. If a font does not have any concept of varying strengths of stretch values, its stretch value is mapped according table in the property definition. If the matching set includes faces with width values containing the font-stretch desired value, faces with other width values are removed from the matching set. If there is no face which contains the desired value, a stretch value is chosen using the rules below:
      • If the desired stretch value is less than 100, stretch values below the desired stretch value are checked in descending order followed by stretch values above the desired stretch value in ascending order until a match is found.
      • Otherwise, stretch values above the desired stretch value are checked in ascending order followed by stretch values below the desired stretch value in descending order until a match is found.
      Once the closest matching width has been determined by this process, faces with widths which do not include this determined width are removed from the matching set.
    2. font-style is tried next. If the value of font-style is italic, italic faces are checked first, then oblique, then normal faces. If the value is oblique, oblique faces are checked first, then italic faces and then normal faces. If the value is normal, normal faces are checked first, then oblique faces, then italic faces. When checking oblique faces, an oblique angle is chosen using the rules below:
      • If the desired oblique angle is greater than or equal to 0deg and less than 20deg, oblique angles below the desired oblique angle are checked in descending order until 0deg or a negative value is reached. Next, oblique angles above the desired oblique angle are checked in ascending order.
      • If the desired oblique angle is greater than or equal to 20deg, oblique angles greater than the desired oblique angle are checked in ascending order. Next, oblique angles less than or equal to 20deg are checked in descending order until 0deg or a negative value is reached.
      • Otherwise, the same steps as above are performed, substituting negative values for the positive ones above.
      During this operation, if an oblique font does not have any concept of varying oblique angles, it is assumed to have an angle of 20deg. If the search for a normal or italic face successfully determined a font, faces with other style values are excluded from the matching set. Otherwise, if the search for an oblique face successfully determined a font, fonts with oblique angles which do not include this determined angle are excluded from the matching set. User agents are permitted to distinguish between italic and oblique faces within platform font families but this is not required, so all italic or oblique faces may be treated as italic faces or oblique faces with an angle of 20deg. However, within font families defined via @font-face rules, italic and oblique faces must be distinguished using the value of the font-style descriptor. For families that lack any italic or oblique faces, users agents may create artificial oblique faces, if this is permitted by the value of the font-synthesis property.
    3. font-weight is matched next. If a font does not have any concept of varying strengths of weights, its weight is mapped according list in the property definition. If bolder/lighter relative weights are used, the effective weight is calculated based on the inherited weight value, as described in the definition of the font-weight property. Given the desired weight and the weight ranges of faces in the matching set after the steps above, if the desired weight is available inside the weight range of a font in the matching set, then that face matches. Otherwise, a weight is chosen using the rules below:
      • If the desired weight is 400, 500 is checked first and then the rule for desired weights less than 450 is used.
      • If the desired weight is 500, 400 is checked first and then the rule for desired weights less than 450 is used.
      • If the desired weight is less than 450, weights below the desired weight are checked in descending order followed by weights above the desired weight in ascending order until a match is found.
      • If the desired weight is greater than or equal to 450 and not equal to 500, weights above the desired weight are checked in ascending order followed by weights below the desired weight in descending order until a match is found.
      Once the closest matching weight has been determined by this process, faces with weights which do not include this determined width are removed from the matching set.
    4. font-size must be matched within a UA-dependent margin of tolerance. (Typically, sizes for scalable fonts are rounded to the nearest whole pixel, while the tolerance for bitmapped fonts could be as large as 20%.) Further computations, e.g., by em values in other properties, are based on the font-size value that is used, not the one that is specified.
    Note that more than one font may be remaining in the matching set after performing the above steps. If so, the user agent must choose a single font from the matching set and continue these steps with it. The choice of which font to choose may differ between multiple user agents and multiple operating system platforms; however, it must not differ between two elements in the same document.
  5. If the matched face is defined via @font-face rules, user agents must use the procedure below to select a single font:

    1. If the font resource has not been loaded and the range of characters defined by the unicode-range descriptor value includes the character in question, load the font.
    2. After downloading, if the effective character map supports the character in question, select that font.

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

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

  6. If no matching face exists or the matched face does not contain a glyph for the character to be rendered, the next family name is selected and the previous three steps repeated. Glyphs from other faces in the family are not considered. The only exception is that user agents may optionally substitute a synthetically obliqued version of the default face if that face supports a given glyph and synthesis of these faces is permitted by the value of the font-synthesis property. For example, a synthetic italic version of the regular face may be used if the italic face doesn’t support glyphs for Arabic.

  7. If there are no more font families to be evaluated and no matching face has been found, then the user agent performs a system font fallback procedure to find the best match for the character to be rendered. The result of this procedure may vary across user agents.
  8. If a particular character cannot be displayed using any font, the user agent should indicate by some means that a character is not being displayed, displaying either a symbolic representation of the missing glyph (e.g. using a Last Resort Font) or using the missing character glyph from a default font.

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

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

4.3. Cluster matching

Import from level 3

5. Font Feature and Variation Resolution

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

5.1. Default features

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

5.2. Feature and variation precedence

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

  1. Font features enabled by default, including features required for a given script.
  2. Font variations as enabled by the font-weight, font-stretch, and font-style properties.
  3. If the font is defined via an @font-face rule, the font features implied by the font-variant descriptor in the @font-face rule.
  4. If the font is defined via an @font-face rule, the font features implied by the font-feature-settings descriptor in the @font-face rule.
  5. Font variations implied by the value of the font-optical-sizing property.
  6. Font features implied by the value of the font-variant property, the related font-variant subproperties and any other CSS property that uses OpenType features (e.g. the font-kerning property).
  7. Feature settings determined by properties other than font-variant or font-feature-settings. For example, setting a non-default value for the letter-spacing property disables common ligatures.
  8. Font variations implied by the value of the font-variation-settings property.
  9. Font features implied by the value of font-feature-settings property.

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

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

5.3. Feature precedence examples

With the styles below, numbers are rendered proportionally when used within a paragraph but are shown in tabular form within tables of prices:

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

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

When the font-variant descriptor is used within an @font-face rule, it only applies to the font defined by that rule.

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

body {
  font-family: MainText, Helvetica;
}

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

In this case, old-style numerals will be used throughout but only where the font "MainText" is used. Just as in the previous example, tabular values will be used in price tables since tabular-nums appears in a general style rule and its use is mutually exclusive with proportional-nums. Stylistic alternate sets will only be used where MainText is used.

The @font-face rule can also be used to access font features in locally available fonts via the use of local() in the src descriptor of the @font-face definition:

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

body { font-family: BodyText, serif; }

If available, a Japanese font "Hiragino Maru Gothic" will be used. When text rendering occurs, Japanese kana will be proportionally spaced and Latin text will be italicised. Text rendered with the fallback serif font will use default rendering properties.

In the example below, discretionary ligatures are enabled only for a downloadable font but are disabled within spans of class "special":

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

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

Suppose one adds a rule using font-feature-settings to enable discretionary ligatures:

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

In this case, discretionary ligatures will be rendered within spans of class "special". This is because both the font-feature-settings and font-variant-ligatures properties apply to these spans. Although the 'no-discretionary ligatures' setting of font-variant-ligatures effectively disables the OpenType dlig feature, because the font-feature-settings' is resolved after that, the dlig value reenables discretionary ligatures.

6. Font Variation Properties

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

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

Name: font-optical-sizing
Value: auto | none
Initial: auto
Applies to: all elements
Inherited: yes
Percentages: n/a
Media: visual
Computed value: as specified
Canonical order: per grammar
Animatable: no

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

auto
The user agent may modify the shape of glyphs based on the font-size and the pixel density of the screen. For OpenType and TrueType fonts using font variations, this is often done by using the "opsz" font variation.
none
The user agent must not modify the shape of glyphs for optical size.
text with different optical sizes, normalized to similar physical sizes

Each size of Century Expanded as it existed in analog metal form. The different optical sizes, normalized here to the same physical size, have design variations to maintain stylistic traits and improve readability.

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

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

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

Name: font-variation-settings
Value: normal | [ <string> <number>] #
Initial: normal
Applies to: all elements
Inherited: yes
Percentages: n/a
Media: visual
Computed value: as specified
Canonical order: per grammar
Animatable: yes (see description)

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

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

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

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

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

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

Values are allowed to be fractional or negative.

If the same axis name appears twice, the second one supercedes the first.

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

Animating font-variation-settings is possible using a mechanism similar to animating the transform property: Two declarations of font-feature-settings can be animated between if they are "like". "Like" declarations are ones where the same set of properties appear (in any order). If two declarations are "like" then animation occurs pairwise between corresponding values in the declarations. Otherwise, animation is not possible. In this situation, the "from" values of the animation are swapped to the "to" values at an unspecified time during the animation.

7. Color Font Support

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

Add a picture.

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

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

Name: font-palette
Value: normal | light | dark | <palette-identifier>
Initial: normal
Applies to: all elements
Inherited: yes
Percentages: N/a
Media: visual
Computed value: As specified
Canonical order: per grammar
Animatable: No (see below)
normal
User-Agents attempt to treat the color font as closely as possible to a non-color font. In particular, user-agents use a palette which will yield the best default result for reading. User-agents may take the computed value of the color property into consideration when making this decision. User agents may also construct and use a palette not defined in the font.
light
Some color font formats include metadata marking certain palettes as applicable on a light (close to white) background. This keyword causes the user-agent to use the first available palette in the font file marked this way. If the font file format does not account for this metadata, or no palette in the font is marked this way, this value behaves as normal.
dark
Some color font formats include metadata marking certain palettes as applicable on a dark (close to black) background. This keyword causes the user-agent to use the first available palette in the font file marked this way. If the font file format does not account for this metadata, or no palette in the font is marked this way, this value behaves as normal.
<palette-identifier>
This value identifies an author-define palette to use. Users can define a palette by using the '@font-palette-values' rule. If no applicable '@font-palette-values' rule is present, this value behaves as normal.

Add examples and pictures.

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

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

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

The '@font-palette-values' rule consists of the '@font-palette-values' at-keyword followed by a block of descriptor declarations. In terms of the grammar, this specification defines the following productions:

font_palette_values_rule  : FONT_PALETTE_VALUES_SYM S* '{' S* descriptor_declaration? [ ';' S* descriptor_declaration? ]* '}' S*
  ;

descriptor_declaration
  : property ':' S* expr
  ;

The following new token is introduced:

@{F}{O}{N}{T}{-}{P}{A}{L}{E}{T}{T}{E}{-}{V}{A}{L}{U}{E}{S} {return FONT_PALETTE_VALUES_SYM;}

Modify Handover Sans’s color palette

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

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

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

An author-defined font color palette is only available to the documents that reference it. Using an author-defined color palette outside of the documents that reference it would constitute a security leak since the contents of one page would be able to affect other pages, something an attacker could use as an attack vector.

This at-rule follows the forward-compatible parsing rules of CSS. Like properties in a declaration block, declarations of any descriptors that are not supported by the user agent must be ignored. @font-palette-values rules require a font-family descriptor; if it is missing, the @font-palette-values rule is invalid and must be ignored entirely.

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

7.3. Font family: the font-family descriptor

Name: font-family
For: @font-palette-values
Value: <font-family>

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

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

Name: base-palette
For: @font-palette-values
Value: <integer>

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

Rename Handover Sans’s 3rd color palette

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

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

7.5. Overriding a color in the palette: The <integer> descriptor

Name: <integer>
For: @font-palette-values
Value: <color>

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

Create a new color palette for Handover Sans

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

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

Appendix A: Mapping platform font properties to CSS properties

Import from level 3

8. Minimum and maximum font-size

Define new properties to control the minimum and maximum font-size, min-font-size and max-font-size.

9. New generic font families

For most languages and scripts, existing generics can be mapped to something comparable to that script. That’s useful for the web so that generics like serif and sans-serif map to something reasonable independent of the language of the content. But typographic traditions vary widely across the world and many scripts have a variety of common typeface designs that don’t map cleanly into these existing generics. In situations where a similar typeface is used across a wide variety of platforms, it’s useful to extend the set of predefined CSS generic font families to cover these type styles.

Add new generic font families for:

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

10. Font fallback for emoji codepoints

Many codepoints supported by emoji fonts overlap with codepoints supported by existing fonts. In fallback situations where it’s not clear whether to use an emoji font or not, UTR51 defines a the default behavior for a given codepoint.

Authors can explicitly control emoji or text display using selectors.

Example of author control over emoji/text styles

11. Acknowledgments

The CSS Working group would like to thank:

Peter Constable for assorted language fixes.

Optical sizing image prepared by Nick Sherman.

Conformance

Document conventions

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

Note, this is an informative note.

Advisements are normative sections styled to evoke special attention and are set apart from other normative text with <strong class="advisement">, like this: UAs MUST provide an accessible alternative.

Conformance classes

Conformance to this specification is defined for three conformance classes:

style sheet
A CSS style sheet.
renderer
A UA that interprets the semantics of a style sheet and renders documents that use them.
authoring tool
A UA that writes a style sheet.

A style sheet is conformant to this specification if all of its statements that use syntax defined in this module are valid according to the generic CSS grammar and the individual grammars of each feature defined in this module.

A renderer is conformant to this specification if, in addition to interpreting the style sheet as defined by the appropriate specifications, it supports all the features defined by this specification by parsing them correctly and rendering the document accordingly. However, the inability of a UA to correctly render a document due to limitations of the device does not make the UA non-conformant. (For example, a UA is not required to render color on a monochrome monitor.)

An authoring tool is conformant to this specification if it writes style sheets that are syntactically correct according to the generic CSS grammar and the individual grammars of each feature in this module, and meet all other conformance requirements of style sheets as described in this module.

Requirements for Responsible Implementation of CSS

The following sections define several conformance requirements for implementing CSS responsibly, in a way that promotes interoperability in the present and future.

Partial Implementations

So that authors can exploit the forward-compatible parsing rules to assign fallback values, CSS renderers must treat as invalid (and ignore as appropriate) any at-rules, properties, property values, keywords, and other syntactic constructs for which they have no usable level of support. In particular, user agents must not selectively ignore unsupported property values and honor supported values in a single multi-value property declaration: if any value is considered invalid (as unsupported values must be), CSS requires that the entire declaration be ignored.

Implementations of Unstable and Proprietary Features

To avoid clashes with future stable CSS features, the CSSWG recommends following best practices for the implementation of unstable features and proprietary extensions to CSS.

Implementations of CR-level Features

Once a specification reaches the Candidate Recommendation stage, implementers should release an unprefixed implementation of any CR-level feature they can demonstrate to be correctly implemented according to spec, and should avoid exposing a prefixed variant of that feature.

To establish and maintain the interoperability of CSS across implementations, the CSS Working Group requests that non-experimental CSS renderers submit an implementation report (and, if necessary, the testcases used for that implementation report) to the W3C before releasing an unprefixed implementation of any CSS features. Testcases submitted to W3C are subject to review and correction by the CSS Working Group.

Further information on submitting testcases and implementation reports can be found from on the CSS Working Group’s website at http://www.w3.org/Style/CSS/Test/. Questions should be directed to the public-css-testsuite@w3.org mailing list.

Index

Terms defined by this specification

Terms defined by reference

References

Normative References

[CSS-COLOR-3]
CSS Color Module Level 3 URL: https://drafts.csswg.org/css-color-3/
[CSS-COLOR-4]
Tab Atkins Jr.; Chris Lilley. CSS Color Module Level 4. URL: https://drafts.csswg.org/css-color/
[CSS-FONTS-3]
John Daggett. CSS Fonts Module Level 3. URL: http://dev.w3.org/csswg/css-fonts/
[CSS-TEXT-3]
Elika Etemad; Koji Ishii. CSS Text Module Level 3. URL: http://dev.w3.org/csswg/css-text-3/
[CSS-TRANSFORMS-1]
Simon Fraser; et al. CSS Transforms Module Level 1. URL: http://dev.w3.org/csswg/css-transforms/
[CSS-VALUES-3]
Tab Atkins Jr.; Elika Etemad. CSS Values and Units Module Level 3. URL: https://drafts.csswg.org/css-values/
[CSS22]
Bert Bos. Cascading Style Sheets Level 2 Revision 2 (CSS 2.2) Specification. URL: http://dev.w3.org/csswg/css2/
[OPENTYPE]
OpenType specification. URL: http://www.microsoft.com/typography/otspec/default.htm
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[SVG]
Jon Ferraiolo. Scalable Vector Graphics (SVG) 1.0 Specification. 4 September 2001. REC. URL: https://www.w3.org/TR/SVG/
[UNICODE]
The Unicode Standard. URL: http://www.unicode.org/versions/latest/

Property Index

Name Value Initial Applies to Inh. %ages Media Ani­mat­able Anim­ation type Canonical order Com­puted value
font-weight normal | bold | bolder | lighter | <number> normal all elements yes n/a visual discrete per grammar numeric weight value (see description)
font-stretch normal | ultra-condensed | extra-condensed | condensed | semi-condensed | semi-expanded | expanded | extra-expanded | ultra-expanded | <percentage> normal all elements yes Not resolved. visual As <number> per grammar numeric weight value (see description)
font-style normal | italic | oblique <angle>? normal all elements yes n/a visual If both "from" and "to" values are "oblique", then yes, as an <angle>. Otherwise, no. per grammar As specified
font-size <absolute-size> | <relative-size> | <length-percentage> medium all elements yes refer to parent element’s font size visual As <length> per grammar absolute length
font-synthesis none | [ weight || style || small-caps ] weight style small-caps all elements yes N/A visual no per grammar as specified
font-optical-sizing auto | none auto all elements yes n/a visual no per grammar as specified
font-variation-settings normal | [ <string> <number>] # normal all elements yes n/a visual yes (see description) per grammar as specified
font-palette normal | light | dark | <palette-identifier> normal all elements yes N/a visual No (see below) per grammar As specified

@font-face Descriptors

Name Value Initial
src [ <url> [ format( <string> # )]? | <font-face-name> ] # N/A
font-style normal | italic | oblique [ <angle> | <angle>-<angle> ] ? normal
font-weight normal | bold | [ <number> | <number>-<number> ] normal
font-stretch normal | ultra-condensed | extra-condensed | condensed | semi-condensed | semi-expanded | expanded | extra-expanded | ultra-expanded | [ <percentage> | <percentage>-<percentage> ] normal

@font-palette-values Descriptors

Name Value Initial
font-family <font-family>
base-palette <integer>
<integer> <color>

Issues Index

Please note that OpenType/TrueType variable font support is still in intial stages of specification and implementation. Please comment on any bugs in this spec at https://github.com/w3c/csswg-drafts/issues. Also, please note that this spec is incomplete and only includes some of the text from https://www.w3.org/TR/css-fonts-3/.
Import from level 3
Import from level 3
Add a picture.
Add examples and pictures.
Import from level 3
Add system-ui fingerprinting issue to Security and Privacy Considerations section per discussion.