@font-face {
    font-family: "AccuroVar";
    src: url("accurovar.otf") format("opentype");
    font-named-instance: "Grotesque";
    font-variation-settings: "XHGT" 0.7;
}

Font request guidelines

Font loading guidelines

@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;
}

Font fetching requirements

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

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

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

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

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

Controlling Font Display Per Font-Face: the 'font-display!!descriptor' descriptor

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

auto

The font display policy is user-agent-defined. Note: Many browsers have a default policy similar to that specified by ''display/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.

Controlling Font Display Per Font-Family via ''@font-feature-values''

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

Default font language overriding: the 'font-language-override' descriptor

Name: font-language-override
Value: normal | <>
For: @font-face
Initial: normal

Font Matching Algorithm

Localized name matching

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' property, and the results will be identical on all systems:

Matching font styles

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' property. 2. If the family name is a generic family keyword, the user agent looks up the appropriate font family name to be used. User agents may choose the generic font family to use based on the language of the containing element or the Unicode range of the character. 3. For other family names, the user agent attempts to find the family name among fonts defined via ''@font-face'' rules and then among available installed fonts, matching names with a [[#localized-name-matching]] as outlined in the section above. If the font resources defined for a given face in an ''@font-face'' rule are either not available or contain invalid font data, then the face should be treated as not present in the family. If no faces are present for a family defined via ''@font-face'' rules, the family should be treated as missing; matching a platform font with the same name must not occur in this case. 4. If a font family match occurs, the user agent assembles the set of font faces in that family and then narrows the set to a single face using other font properties in the order given below. Fonts might be present in this group which can support a range of 'font-stretch!!property', 'font-style!!property', or 'font-weight!!property' 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!!property', 'font-style!!property', and 'font-weight!!property' 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-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!!property' 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!!property' desired value, faces with width values which do not include the desired width value are removed from the matching set. If there is no face which contains the desired value, a stretch value is chosen using the rules below: * If the desired stretch value is less than or equal to 100, stretch values below the desired stretch value are checked in descending order followed by stretch values above the desired stretch value in ascending order until a match is found. * Otherwise, stretch values above the desired stretch value are checked in ascending order followed by stretch values below the desired stretch value in descending order until a match is found. Once the closest matching width has been determined by this process, faces with widths which do not include this determined width are removed from the matching set.
This search algorithm can be thought of as a distance function, where the lowest-distance value present in the font family is selected, and all fonts not including that value are eliminated. Consider a font family with three fonts, named A, B, and C, each with associated supported ranges for the 'font-stretch!!property' descriptor. If an element is styled with "font-stretch: 125", the search algorithm can be visualized as follows: The font stretch ranges supported by fonts A, B, and C are shown in the graph above. As you can see, because font B contains the minimum stretch value across the entire family, font B would be selected by this algorithm. However, if font B were somehow eliminated from the family, font C would then contain the lowest distance in the family, so it would be selected.
Similar to the previous example, here is the conceptual distance graph for an element styled with "font-stretch: 75": As you can see, because font B contains the minimum stretch value across the entire family, font B would be selected by this algorithm. However, if font B were somehow eliminated from the family, font A would then contain the lowest distance in the family, so it would be selected.
2. 'font-style!!property' is tried next (see [[#font-style-matching]]). If a font does not have any concept of varying strengths of italics or oblique angles, its style is mapped according to the description in the 'font-style!!property' property definition. If the value of 'font-style!!property' is ''italic'': 1. If the matching set includes faces with italic values containing the mapped value of ''italic'', faces, then faces with italic values which do not include the desired italic mapped value are removed from the matching set. 2. Otherwise, italic values above the desired italic value are checked in ascending order followed by italic values below the desired italic value, until 0 is hit. Only positive values of italic values are checked in this stage. 3. If no match is found, oblique values greater than or equal to 20deg are checked in ascending order followed by oblique values below 20deg in descending order, until 0 is hit. Only positive values of oblique values are checked in this stage. ISSUE: The threshold for preferring oblique over normal should be lower than the average angle. 4. If no match is found, italic values less than or equal to 0 are checked in descending order until a match is found. 5. If no match is found, oblique values less than or equal to 0deg are checked in descending order until a match is found.
Similar to the previous example, here is the conceptual distance graph for an element styled with "font-style: italic": As you can see, because font D contains the minimum italic value across the entire family, font D would be selected by this algorithm. However, if font D were somehow eliminated from the family, font E would then contain the lowest distance in the family, so it would be selected. If E were eliminated, C would be selected. If C were eliminated, font B would not be chosen immediately; instead, oblique values would be consulted and an oblique value might be chosen. However, if no oblique value is chosen, font B would then be selected, followed by font A.
If the value of 'font-style!!property' is ''oblique'' and the requested angle is greater than or equal to 20deg,
1. If the matching set includes faces with oblique values containing the value of ''oblique'', faces with oblique values which do not include the desired oblique value are removed from the matching set. 2. Otherwise, oblique values above the desired oblique value are checked in ascending order followed by oblique values below the desired oblique value, until 0 is hit. Only positive values of oblique values are checked in this stage. 3. If no match is found, italic values greater than or equal to 1 are checked in ascending order followed by italic values below 1 in descending order, until 0 is hit. Only positive values of italic values are checked in this stage. 4. If no match is found, oblique values less than or equal to 0deg are checked in descending order until a match is found. 5. If no match is found, italic values less than or equal to 0 are checked in descending order until a match is found.
Similar to the previous example, here is the conceptual distance graph for an element styled with "font-style: oblique 40deg": As you can see, because font D contains the minimum oblique value across the entire family, font D would be selected by this algorithm. However, if font D were somehow eliminated from the family, font E would then contain the lowest distance in the family, so it would be selected. If E were eliminated, C would be selected. If C were eliminated, font B would not be chosen immediately; instead, italic values would be consulted and an italic value might be chosen. However, if no italic value is chosen, font B would then be selected, followed by font A.
If the value of 'font-style!!property' is ''oblique'' and the requested angle is greater than or equal to 0deg and less than 20deg,
1. If the matching set includes faces with oblique values containing the value of ''oblique'', faces with oblique values which do not include the desired oblique value are removed from the matching set. 2. Otherwise, oblique values below the desired oblique value are checked in descending order until 0 is hit, followed by oblique values above the desired oblique value. Only positive values of oblique values are checked in this stage. 3. If no match is found, italic values less than 1 are checked in descending order until 0 is hit, followed by italic values above 1 in ascending order. Only positive values of italic values are checked in this stage. 4. If no match is found, oblique values less than or equal to 0deg are checked in descending order until a match is found. 5. If no match is found, italic values less than or equal to 0 are checked in descending order until a match is found.
Similar to the previous example, here is the conceptual distance graph for an element styled with "font-style: oblique 13deg": As you can see, because font D contains the minimum oblique value across the entire family, font D would be selected by this algorithm. However, if font D were somehow eliminated from the family, font C would then contain the lowest distance in the family, so it would be selected. If C were eliminated, E would be selected. If E were eliminated, font B would not be chosen immediately; instead, italic values would be consulted and an italic value might be chosen. However, if no italic value is chosen, font B would then be selected, followed by font A.
If the value of 'font-style!!property' is ''oblique'' and the requested angle is less than 0deg and greater than -20deg, follow the steps above, except with the negated values and opposite directions. If the value of 'font-style!!property' is ''oblique'' and the requested angle is less than or equal to -20deg, follow the steps above, except with the negated values and opposite directions. If the value of 'font-style!!property' is ''font-style/normal'', 1. Oblique values greater than or equal to 0 are checked in ascending order. 2. If no match is found, italic values greater than or equal to 0 are checked in ascending 3. If no match is found, oblique values less than 0deg are checked in descending order until a match is found. 4. If no match is found, italic values less than 0 are checked in descending order until a match is found.
Similar to the previous example, here is the conceptual distance graph for an element styled with "font-style: normal": As you can see, because font C contains the minimum oblique value across the entire family, font C would be selected by this algorithm. However, if font C were somehow eliminated from the family, font B would not be chosen immediately; instead, italic values would be consulted and an italic value might be chosen. However, if no italic value is chosen, font B would then be selected, followed by font A.
If an oblique angle was found in the above search, all faces which don't include that oblique angle are excluded from the matching set. Otherwise, if an italic value was found in the above search, all faces which don't include that italic value are excluded from the matching set. User Agents are not required to distinguish between italic and oblique fonts. In such User Agents, the 'font-style!!property' matching steps above are performed by mapping both italic values and oblique angles onto a common scale. The exact nature of this mapping is undefined, however, an italic value of 1 must map to the same value that an oblique angle of 20deg maps to. Within font families defined via ''@font-face'' rules, italic and oblique faces must be distinguished using the value of the 'font-style!!descriptor' descriptor. For families that lack any italic or oblique faces, user agents may create artificial oblique faces, if this is permitted by the value of the 'font-synthesis' property. 3. 'font-weight!!property' 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' property. If the matching set after performing the steps above includes faces with weight values containing the font-weight desired value, faces with weight values which do not include the desired font-weight value are removed from the matching set. If there is no face which contains the desired value, a weight value is chosen using the rules below: * If the desired weight is inclusively between 400 and 500, weights greater than or equal to the target weight are checked in ascending order until 500 is hit and checked, followed by weights less than the target weight in descending order, followed by weights greater than 500, until a match is found. * If the desired weight is less than 400, weights less than or equal to the desired weight are checked in descending order followed by weights above the desired weight in ascending order until a match is found. * If the desired weight is greater than 500, weights greater than or equal to the desired weight are checked in ascending order followed by weights below the desired weight in descending order until a match is found.
Similar to the previous example, here is the conceptual distance graph for an element styled with "font-weight: 400": As you can see, because font B contains the minimum distance across the entire family, font B would be selected by this algorithm. However, if font B were somehow eliminated from the family, font D would then contain the lowest distance in the family, so it would be selected. If D were eliminated, A would be selected, followed by fonts C and then E.
Similar to the previous example, here is the conceptual distance graph for an element styled with "font-weight: 450": As you can see, because font C contains the minimum distance across the entire family, font C would be selected by this algorithm. However, if font C were somehow eliminated from the family, font D would then contain the lowest distance in the family, so it would be selected. If D were also eliminated, B would be selected, followed by fonts A and then E.
Similar to the previous example, here is the conceptual distance graph for an element styled with "font-weight: 500": As you can see, because font D contains the minimum distance across the entire family, font D would be selected by this algorithm. However, if font D were somehow eliminated from the family, font B would then contain the lowest distance in the family, so it would be selected. If B were eliminated, C would be selected, followed by fonts A and then E.
Similar to the previous example, here is the conceptual distance graph for an element styled with "font-weight: 300": As you can see, because font B contains the minimum distance across the entire family, font B would be selected by this algorithm. However, if font B were somehow eliminated from the family, font A would then contain the lowest distance in the family, so it would be selected. If A were eliminated, C would be selected.
Once the closest matching weight has been determined by this process, faces with weights which do not include this determined weight are removed from the matching set. Note: There is a small behavior change between [[CSS-FONTS-3]] and this specification with the animation of the 'font-weight!!property' property. Previously, interpolated values of font-weight were rounded to their closest multiple of 100, and the font-matching algorithm was run on these rounded values. In this specification, the font-matching algorithm is able to accept any value, so no rounding occurs. The small behavior change is due to the discontinuous nature of the font-matching algorithm. 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 might be remaining in the matching set after performing the above steps. If so, the user agent must choose a single font from the matching set and continue these steps with it. The choice of which font to choose can differ between multiple user agents and multiple operating system platforms; however, it must not differ between two elements in the same document.
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 must 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 might 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 installed font fallback procedure to find the best match for the character to be rendered. The result of this procedure can vary across user agents. 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.

Cluster matching

1. For each family in the font list, a face is chosen using the style selection rules defined in the previous section.
   1. If all characters in the sequence b + c1 + c2 … are completely supported by the font, select this font for the sequence.
   2. 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 equiavlent character for the entire cluster.
2. If no font was found in the font list in step 1:
   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]]
   2. Otherwise, the user agent may optionally use system font fallback to match a font that supports the entire cluster.
3. 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.

Character handling issues

Font Feature Properties

Glyph selection and positioning

Language-specific display

Kerning: the 'font-kerning' property

Ligatures: the 'font-variant-ligatures' property

Subscript and superscript forms: the 'font-variant-position' property

Capitalization: the 'font-variant-caps' property

Numerical formatting: the 'font-variant-numeric' property

Alternates and swashes: the 'font-variant-alternates' property

Name: font-variant-alternates

Value: normal | [ stylistic(<>) ||
                  historical-forms ||
                  styleset(<>#) ||
                  character-variant(<>#) ||
                  swash(<>) ||
                  ornaments(<>) ||
                  annotation(<>) ]
Initial: normal
Applies to: all elements
Inherited: yes
Percentages: n/a
Computed value: as specified
Media: visual
Animatable: no

<feature-value-name> = <>

> with a custom <>, which is then used in this property to select specific alternates:

@font-feature-values Noble Script { @swash { swishy: 1; flowing: 2; } }

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

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

/* these two style rules are effectively the same */

p { font-variant-alternates: swash(unknown-value); } /* not a defined value, ignored */
p { font-variant-alternates: normal; }

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

normal

None of the features listed below are enabled.

historical-forms

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

stylistic(<>)

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

styleset(<>#)

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

character-variant(<>#)

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

swash(<>)

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

ornaments(<>)

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

annotation(<>)

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

Defining font specific alternates: the ''@font-feature-values'' rule

Several of the possible values of 'font-variant-alternates' listed above are labeled as font specific. For these features fonts may define not just a single glyph but a set of alternate glyphs with an index to select a given alternate. Since these are font family specific, the ''@font-feature-values'' rule is used to define named values for these indices for a given family.

In the case of the swash Q in the example shown above, the swash could be specified using these style rules:

	@font-feature-values Jupiter Sans {
	  @swash {
		delicate: 1;
		flowing: 2;
	  }
	}

	h2 { font-family: Jupiter Sans, sans-serif; }

	/* show the second swash variant in h2 headings */
	h2:first-letter { font-variant-alternates: swash(flowing); }

	<h2>Quick</h2>

When Jupiter Sans is present, the second alternate swash alternate will be displayed. When not present, no swash character will be shown, since the specific named value "flowing" is only defined for the Jupiter Sans family. The @-mark indicates the name of the property value for which a named value can be used. The name "flowing" is chosen by the author. The index that represents each alternate is defined within a given font's data.

Basic syntax

An ''@font-feature-values'' rule is composed of a list of font families followed by a block containing individual ''feature value blocks'' that take the form of @-rules. Each block defines a set of named values for a specific font feature when a given set of font families is used. Effectively, they define a mapping of ⟨family, feature, ident⟩ → ⟨values⟩ where ⟨values⟩ are the numeric indices used for specific features defined for a given font.

@font-feature-values = @font-feature-values <># { <> }

<> = <> | <>+

<> = <> { <> }

<> = @stylistic | @historical-forms | @styleset | @character-variant
	| @swash | @ornaments | @annotation

<> = <>+

Feature value blocks are handled as at-rules, they consist of everything up to the next block or semi-colon, whichever comes first. The font family list is a comma-delimited list of font family names that match the definition of <> for the 'font-family!!property' property. This means that only named font families are allowed, rules that include generic or system fonts in the list of font families are syntax errors. However, if a user agent defines a generic font to be a specific named font (e.g. Helvetica), the settings associated with that family name will be used. If syntax errors occur within the font family list, the entire rule must be ignored. Within feature value blocks, the feature type is '@' followed by the name of one of the font specific property values of 'font-variant-alternates' (e.g. ''@swash''). The identifiers used within feature value definitions follow the rules of CSS user identifiers and are case-sensitive. They are unique only for a given set of font families and feature type. The same identifier used with a different feature type is treated as a separate and distinct value. If the same identifier is defined multiple times for a given feature type and font family, the last defined value is used. Values associated with a given identifier are limited to integer values 0 or greater. When syntax errors occur within a feature value definition, such as invalid identifiers or values, the entire feature value definition must be omitted, just as syntax errors in style declarations are handled. When the feature type is invalid, the entire associated feature value block must be ignored.

Rules that are equivalent given syntax error handling:

@font-feature-values Bongo {
	  @swash { ornate: 1; }
	  annotation { boxed: 4; } /* should be @annotation! */
	  @swash { double-loops: 1; flowing: -1; } /* negative value */
	  @ornaments ; /* incomplete definition */
	  @styleset { double-W: 14; sharp-terminals: 16 1 } /* missing ; */
	  redrum  /* random editing mistake */
	}

The example above is equivalent to:

@font-feature-values Bongo {
	  @swash { ornate: 1; }
	  @swash { double-loops: 1; }
	  @styleset { double-W: 14; sharp-terminals: 16 1; }
	}

If multiple ''@font-feature-values'' rules are defined for a given family, the resulting values definitions are the union of the definitions contained within these rules. This allows a set of named values to be defined for a given font family globally for a site and specific additions made per-page.

Using both site-wide and per-page feature values:

	site.css:

	  @font-feature-values Mercury Serif {
		@styleset {
		  stacked-g: 3; /* "two-storey" versions of g, a */
		  stacked-a: 4;
		}
	  }

	page.css:

	  @font-feature-values Mercury Serif {
		@styleset {
		  geometric-m: 7; /* alternate version of m */
		}
	  }

	  body {
		font-family: Mercury Serif, serif;

		/* enable both the use of stacked g and alternate m */
		font-variant-alternates: styleset(stacked-g, geometric-m);
	  }

Using a commonly named value allows authors to use a single style rule to cover a set of fonts for which the underlying selector is different for each font. If either font in the example below is found, a circled number glyph will be used:

@font-feature-values Taisho Gothic {
		  @annotation { boxed: 1; circled: 4; }
		}

		@font-feature-values Otaru Kisa {
		  @annotation { circled: 1; black-boxed: 3; }
		}

		h3.title {
		  /* circled form defined for both fonts */
		  font-family: Taisho Gothic, Otaru Kisa;
		  font-variant: annotation(circled);
		}

Multi-valued feature value definitions

Most font specific functional values of the 'font-variant-alternates' property take a single value (e.g. ''swash()''). The ''character-variant()'' property value allows two values and ''styleset()'' allows an unlimited number. For the styleset property value, multiple values indicate the style sets to be enabled. Values between 1 and 99 enable OpenType features ss01 through ss99. However, the OpenType standard only officially defines ss01 through ss20. For OpenType fonts, values greater than 99 or equal to 0 do not generate a syntax error when parsed but enable no OpenType features.

@font-feature-values Mars Serif {
	@styleset {
	alt-g: 1;        /* implies ss01 = 1 */
	curly-quotes: 3; /* implies ss03 = 1 */
	code: 4 5;       /* implies ss04 = 1, ss05 = 1 */
	}

	@styleset {
	dumb: 125;        /* >99, ignored */
	}

	@swash {
	swishy: 3 5;     /* more than 1 value for swash, syntax error */
	}
}

p.codeblock {
	/* implies ss03 = 1, ss04 = 1, ss05 = 1 */
	font-variant-alternates: styleset(curly-quotes, code);
}

For character-variant, a single value between 1 and 99 indicates the enabling of OpenType feature cv01 through cv99. For OpenType fonts, values greater than 99 or equal to 0 are ignored but do not generate a syntax error when parsed but enable no OpenType features. When two values are listed, the first value indicates the feature used and the second the value passed for that feature. If more than two values are assigned to a given name, a syntax error occurs and the entire feature value definition is ignored.

@font-feature-values MM Greek {
	@character-variant { alpha-2: 1 2; }   /* implies cv01 = 2 */
	@character-variant { beta-3: 2 3; }    /* implies cv02 = 3 */
	@character-variant { epsilon: 5 3 6; } /* more than 2 values, syntax error, definition ignored */
	@character-variant { gamma: 12; }      /* implies cv12 = 1 */
	@character-variant { zeta:   20 3; }   /* implies cv20 = 3 */
	@character-variant { zeta-2: 20 2; }   /* implies cv20 = 2 */
	@character-variant { silly: 105; }     /* >99, ignored */
	@character-variant { dumb: 323 3; }    /* >99, ignored */
}

#title {
	/* use the third alternate beta, first alternate gamma */
	font-variant-alternates: character-variant(beta-3, gamma);
}

p {
	/* zeta-2 follows zeta, implies cv20 = 2  */
	font-variant-alternates: character-variant(zeta, zeta-2);
}

.special {
	/* zeta follows zeta-2, implies cv20 = 3  */
	font-variant-alternates: character-variant(zeta-2, zeta);
}

Byzantine seal text displayed with character variants

In the figure above, the text in red is rendered using a font containing character variants that mimic the character forms found on a Byzantine seal from the 8th century A.D. Two lines below is the same text displayed in a font without variants. Note the two variants for U and N used on the seal.

@font-feature-values Athena Ruby {
	@character-variant {
	leo-B: 2 1;
	leo-M: 13 3;
	leo-alt-N: 14 1;
	leo-N: 14 2;
	leo-T: 20 1;
	leo-U: 21 2;
	leo-alt-U: 21 4;
	}
}

p {
	font-variant: discretionary-ligatures
				character-variant(leo-B, leo-M, leo-N, leo-T, leo-U);
}

span.alt-N {
	font-variant-alternates: character-variant(leo-alt-N);
}

span.alt-U {
	font-variant-alternates: character-variant(leo-alt-U);
}

<p>ENO....UP͞RSTU<span class="alt-U">U</span>͞<span class="alt-U">U</span>ΚΑΙTỤẠG̣IUPNS</p>

<p>LEON|ΚΑΙCONSTA|NTI<span class="alt-N">N</span>OS..|STOIBAṢ.|LIṢROM|AIO<span class="alt-N">N</span></p>

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

Overall shorthand for font rendering: the 'font-variant!!property' property

Low-level font feature settings control: the 'font-feature-settings' property

Font language override: the 'font-language-override' property

Name: font-language-override
Value: normal | <>
Initial: normal
Applies to: all elements
Inherited: yes
Percentages: N/A
Computed value: as specified
Media: visual
Animatable: no

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

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

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

normal

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

<>

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

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

The Universal Declaration of Human Rights has been translated into a wide variety of languages. In Turkish, Article 9 of this document might be marked up as below:

<body lang="tr">

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

Here the user agent uses the value of the 'lang' attribute when rendering text and appropriately renders this text without 'fi' ligatures. There is no need to use the 'font-language-override!!property' property. However, a given font may lack support for a specific language. In this situation authors may need to use the typographic conventions of a related language that are supported by that font:

<body lang="mk">     <!-- Macedonian lang code -->

body { font-language-override: "SRB"; /* Serbian OpenType language tag */ }

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

As the content creator knows that font specified supports Serbian, the Macedonian text here will be rendered using Serbian typographic conventions.

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!!property', 'font-feature-settings!!property', 'font''font-variation-settings!!property' 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.

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!!property' and 'font-feature-settings!!property' properties is normal. Individual features are only disabled when explicitly overridden by the author, as when 'font-variant-ligatures!!property' 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.

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 are applied, including features required for a given script. 2. Font variations as enabled by the 'font-weight!!property', 'font-stretch!!property', and 'font-style!!property' properties are applied. The application of the value enabled by 'font-style!!property' is affected by font selection, because this property might select an italic or an oblique font. The value applied is the closest matching value as determined by the font matching algorithm. User Agents must apply at most one value due to the 'font-style!!property' property; both "ital" and "slnt" values must not be set together. If the selected font is defined in an ''@font-face'' rule, then the values applied at this step should be clamped to the value of the 'font-weight!!descriptor', 'font-stretch!!descriptor', and 'font-style!!descriptor' descriptors in that ''@font-face'' rule. Then, the values applied in this step should be clamped (possibly again) to the values that are supported by the font. 3. The language specified by the inherited value of lang/xml:lang is applied. 4. If the font is defined via an ''@font-face'' rule, the font language override implied by the 'font-language-override!!descriptor' descriptor in the ''@font-face'' rule are applied. 5. If the font is defined via an ''@font-face'' rule, that ''@font-face'' rule includes at least one valid 'font-named-instance' descriptor with a value other than 'font-named-instance/none', and the loaded font resource includes a named instance with that name according to the [[#localized-name-matching]] rules, then all the variation values represented by that named instance are applied. These values are clamped to the values that are supported by the font. 6. If the font is defined via an ''@font-face'' rule, the font variations implied by the 'font-variation-settings!!descriptor' descriptor in the ''@font-face'' rule are applied. 7. If the font is defined via an ''@font-face'' rule, the font features implied by the 'font-feature-settings!!descriptor' descriptor in the ''@font-face'' rule are applied. 8. The font language override implied by the value of the 'font-language-override!!property' property is applied. 9. Font variations implied by the value of the 'font-optical-sizing!!property' property are applied. 10. Font features implied by the value of the 'font-variant!!property' property, the related 'font-variant!!property' subproperties and any other CSS property that uses OpenType features (e.g. the 'font-kerning!!property' property) are applied. 11. Feature settings determined by properties other than 'font-variant!!property' or 'font-feature-settings!!property' are applied. For example, setting a non-default value for the 'letter-spacing' property disables common ligatures. 12. Font variations implied by the value of the 'font-variation-settings!!property' property are applied. These values should be clamped to the values that are supported by the font. 13. Font features implied by the value of 'font-feature-settings!!property' property are applied. 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' 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.

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.

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

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
Computed value: as specified
Media: visual
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 are often thicker with larger serifs. Larger text often has a more delicate figure with more contrast between thicker and thinner strokes.

auto

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

none

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

'font-size' must be considered when selecting a variation value for the "opsz" axis, but other signals may also be considered. Note: User Agents are expected to supply a value for the "opsz" axis which is close to the used value for 'font-size'. However, User Agents might wish to consider other factors such as pixel density of the screen, or the solid angle the text subtends in the viewer's retina. Experiments have shown, however, that disregarding these other ancillary factors and using only 'font-size' might be the best way for a User Agent to select this value. Pixel density as well as visual size of the text may influence the variation value chosen for 'font-optical-sizing'. When either pixel density or visual size of the text changes in response to a user operation or style change, user agents must not choose a new value for this variation value unless the change is layout-causing. User agents are free to determine which changes are layout-causing. Note: Some user operations, such as pinch-zoom, can be considered not-layout-causing if they do not cause text to reflow. However, other user operations, such as increasing text size for accessiblity purposes, can be considered layout-causing because they cause text to reflow. Similarly, the 'transform' property can be considered not-layout-causing because transforms generally do not cause text to reflow. Each user-agent is free to decide whether or not each operation is layout-changing or not. User Agents must not synthesize optical sizing when it is not performed by the font directly. User Agents must not select a value for the "opsz" axis which is not supported by the font used for rendering the text. This can be accomplished by clamping a chosen value to the range supported by the font.

Low-level font variation settings control: the 'font-variation-settings' property

Name: font-variation-settings
Value: normal | [ <> <>] #
Initial: normal
Applies to: all elements
Inherited: yes
Percentages: n/a
Computed value: as specified
Media: visual
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 ''font-variation-settings/normal'' means that no change in glyph shape, matching, or positioning occurs due to this property. The <> is a case-sensitive OpenType or TrueType variation axis name. As specified in the OpenType / TrueType specifications, axis names contain four ASCII characters. Axis name strings longer or shorter than four characters, or containing characters outside the U+20–7E codepoint range are invalid. Axis names need only match an axis tag defined in the font, so they are not limited to explicitly registered OpenType / TrueType variation axes. Fonts defining custom axis names should follow the name rules defined in the OpenType specification. Axis values not present in the font are ignored and therefore have no effect; a user agent must not attempt to synthesize fallback behavior based on these axis tags. Other axis values within the same CSS 'font-variation-settings' statement are not ignored. Axis values greater or less than the range supported by the font are clamped to the closest value supported by the font. Values are allowed to be fractional or negative. If the same axis name appears more than once, the value associated with the last appearance supersedes any previous value for that axis. This deduplication is observable by accessing the computed value of this property. Although specifically defined for OpenType / TrueType variations, variation axes for other modern font formats that support font variations might be added in the future. Where possible, variations defined for other font formats should attempt to follow the pattern of registered variation axes. Animating font-variation-settings is possible using the following mechanism. Two declarations of font-feature-settings can be animated between if they are "like". "Like" declarations are ones where the same set of properties appear (in any order). Because succesive duplicate properties are applied instead of prior duplicate properties, two declarations can be "like" even if they have differing number of properties. If two declarations are "like" then animation occurs pairwise between corresponding values in the declarations. Otherwise, animation is not possible. In this situation, the "from" values of the animation are swapped to the "to" values at an unspecified time during the animation.

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. Issue: Add a picture.

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 | <>
Initial: normal
Applies to: all elements
Inherited: yes
Percentages: N/a
Computed value: As specified
Media: visual
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 ''font-palette/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 ''font-palette/normal''.

<>

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 ''font-palette/normal''.

Issue: Add examples and pictures.

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). Note: A web author might wish to create multiple palettes for a single font in order to create multiple themes for their web content. A web author might also wish to create matching palettes for multiple fonts to achieve a consistent design across a collection of different fonts. A ''@font-palette-values'' rule represents a palette of colors used in a font. A palette consists of an ordered collection of colors. Using the ''@font-palette-values'' allows a web author to reference a palette existing within a font as well as creating a palette populated with author-defined colors. In addition, it allows overriding a set of colors from a palette in the font with colors described by the web author. The ''@font-palette-values'' rule consists of the ''@font-palette-values'' at-keyword followed by a block of descriptor declarations. It has the following syntax:

        @font-palette-values <> {
            <>
        }
    

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

Modify Handover Sans's color palette

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

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-palette-values/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.

Font family: the 'font-family!!descriptor' descriptor

    Name: font-family
    Value: <<'font-family'>>
    For: @font-palette-values
    Initial: N/A
    

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 <> for the 'font-family!!property' property. This means that only named font families are allowed and rules that including generic or installed fonts in the list of font families are syntax errors. If syntax errors occur within the font family list, the entire rule must be ignored.

Specifying the base palette: the 'base-palette' descriptor

    Name: base-palette
    Value: <> | <>
    For: @font-palette-values
    Initial: N/A
    

The ''@font-palette-values/base-palette'' descriptor accepts either a (zero-based) numerical palette index, or a string, which corresponds to a named palette.

Modify Banner Flag's color palette

            @font-palette-values Festival {
                font-family: Banner Flag;
                base-palette: 'Dark';
                override-color:
                    'Outline' rgb(123, 64, 27),
                    'Base Glyph' currentColor,
                    'Glints' var(--highlight);
            }
            

This descriptor specifies a palette in the font which the containing ''@font-palette-values'' rule uses as an initial value. If no <> key is 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 a <> key is present in the ''@font-palette-values'' rule, each item in the value of thatz descriptor 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'', or if the font does not contain a palette at the index of the value of 'base-palette', it behaves as if ''0'' were specified. If a font does not contain any color palettes, no colors are included in the initial color palette represented by this ''@font-palette-values'' rule. Colors can be added to the color palette by using the <> descriptor in the ''@font-palette-values'' rule. Strings specified in the value of this descriptor are matched according to [[#localized-name-matching]].

Overriding a color from a palette: The 'override-color!!descriptor' descriptor

    Name: override-color
    Value: [ [ <> | <> ] <> ]#
    For: @font-palette-values
    Initial: N/A
    

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. Each item in the comma-separated list represents a tuple of an entry into the palette an a color to replace it with. The '@font-palette-values/override-color' descriptor takes a comma-separated list of palette index entries and colors. Palette index entries in the ''@font-palette-values/override-color'' descriptor are either a (zero-based) palette index entry, or a string, which corresponds to a named palette entry in the selected palette. Strings specified in the value of this descriptor are matched according to [[#localized-name-matching]]. Integer values are zero-indexed. Using CSS Variables is explicitly expected to be valid in the value of this descriptor. Using CSS Variables is disallowed in the key of this descriptor. CSS Variables are resolved in the context of the element to which the 'font-palette' property applies. This means that using 'font-palette' with the same value on two different elements might result in different used palettes because the value of variables inside the ''@font-palette-values'' rule might apply differently in the context of those two elements.

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

Name: font-variant-emoji
Value: auto | text | emoji
Initial: auto
Applies to: all elements
Inherited: yes
Percentages: N/a
Computed value: As specified
Media: visual
Animatable: No (see below)

Issue: Bikeshed the values. This property allows web authors to select whether emoji presentation or text presentation is used for certain emoji code points. Traditionally, these presentation styles were selected by appending Variation Selector 15 (U+FE0E) or Variation Selector 16 (U+FE0F) to certain code points. However, 'font-variant-emoji' allows web authors to set a default presentation style which can replace the variation selectors. Only the code points listed by Unicode as contributing to a Unicode Presentation Sequence are affected by this property. Within this CSS specification, these characters are referred to as Presentation Participating Code Points. This property has no effect on any other characters. This property is expected to affect font fallback; however, the exact nature of the interaction of font fallback with 'font-variant-emoji' is explicitly unspecified. However, a variation selector must be included in a previous cluster as defined by the cluster matching section above. Therefore, the presence of a variation selector is treated as ancillary data to inform the font fallback routine. A natural result of this behavior is that a variation selector must not be rendered in a different font than the previous character. Even when 'font-variant-emoji' is used, the presence of Variation Selector 15 (U+FE0E) or Variation Selector 16 (U+FE0F) in the contents of an element override the rendering specified in 'font-variant-emoji'. Therefore, 'font-variant-emoji' sets a default presentation which the text being rendered can opt out of. Note: Different platforms have different conventions about how to handle emoji presentation sequences. A cross-platform UA might wish to follow the conventions of each inividual platform, or it might wish to use the same approach on all platforms. When tasked with a request for an emoji style rendering, a UA might wish to disregard fonts which do not include color tables. A different UA might wish instead to use the same mechanical cluster fallback algorithm that it would use for any arbitrary cluster. Variation selectors other than FE0E VARIATION SELECTOR-15 and U+FE0F VARIATION SELECTOR-16 must not have any affect on font selection. If one of these variation selectors is present, but unsupported by the font previously selected, the variation selector is ignored. BCP47's -u- extension to the language tag accepted by lang or xml:lang should not be considered when the user-agent decides whether to use emoji presentation or text presentation for a particular character.

auto

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

text

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

emoji

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

To show the emoji form of U+1F6CB COUCH AND LAMP, let CustomEmoji.ttf obey the User Agent's notion of supporting the emoji form of this character, and use the following:

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

Font Taxonomy

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

Installed Fonts

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

Web Fonts

A font may be backed by a remote resource, which must be requested using the User Agent's resource fetching infrastructure. Web Fonts are represented by one of two mechanisms: - ''@font-face'' rules - A ''FontFace'' member of the Document's ''FontFaceSet'' A Web Font must not be accessible in any other Document from the one which either is associated with the ''@font-face'' rule or owns the ''FontFaceSet''. Other applications on the device must not be able to access Web Fonts. Installed Fonts must not be Web Fonts, and Web Fonts must not be Installed Fonts. Web Fonts shadow Installed Fonts, so if an Installed Font has the same family name as a Web Font, the Installed Font is not accessible.

Preinstalled Fonts and User-Installed Fonts

Users may choose to install fonts on their devices. User-Installed Fonts are installed by an explicit action by the user, such as clicking an "Install" button or copying a file into a particular directory on their device. Such fonts are User-Installed Fonts and also are Installed Fonts. Web content authors should not expect the presence of user-installed fonts, because there is no guarantee any user will have performed the action to install a specific font. User Agents may choose to ignore User-Installed Fonts for the purpose of the Font Matching Algorithm. Any Installed Font which is not a User-Installed font is a Preinstalled Font. It is likely that all users of a particular version of a particular Operating System will have the same set of Preinstalled Fonts installed. As such, Web content authors targetting these Operating Systems may wish to use these fonts' family names inside 'font-family!!property' properties.

System Font

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

Object Model

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

The CSSFontFaceRule interface

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

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

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

The CSSFontFeatureValuesRule interface

The CSSRule interface is extended as follows:

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

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

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

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

fontFamily of type CSSOMString

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

value maps of type CSSFontFeatureValuesMap, readonly

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

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

The CSSFontPaletteValuesRule interface

partial interface CSSRule {

  const unsigned short FONT_PALETTE_VALUES_RULE = 15;
};

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

If the value of the 'setlike' functions is a CSSOMString, it is parsed as a solid color (e.g. using the rgb() syntax). If it refers to anything other than a solid color, the call is ignored or returns undefined. The fontFamily and basePalette interfaces are parsed according to the appropriate CSS property syntax.

Appendix A: Mapping platform font properties to CSS properties

This appendix is included as background for some of the problems and situations that are described in other sections. It should be viewed as informative only. Font properties in CSS are designed to be independent of the underlying font formats used; they can be used to specify bitmap fonts, Type1 fonts, SVG fonts in addition to the common TrueType and OpenType fonts. But there are facets of the TrueType and OpenType formats that often cause confusion for authors and present challenges to implementers on different platforms. Originally developed at Apple, TrueType [[TRUETYPE]] was designed as an outline font format for both screen and print. Microsoft joined Apple in developing the TrueType format and both platforms have supported TrueType fonts since then. Font data in the TrueType format consists of a set of tables distinguished with common four-letter tag names, each containing a specific type of data. For example, naming information, including copyright and license information, is stored in the 'name' table. The character map ('cmap') table contains a mapping of character encodings to glyphs. Apple later added additional tables for supporting enhanced typographic functionality; these are now called Apple Advanced Typography, or AAT, fonts. Microsoft and Adobe developed a separate set of tables for advanced typography and called their format OpenType [[OPENTYPE]]. The OpenType specification is standardized at ISO as the Open Font Format [[OPEN-FONT-FORMAT]]. In many cases the font data used under Microsoft Windows or Linux is slightly different from the data used under Apple's Mac OS X because the TrueType format allowed for explicit variation across platforms. This includes font metrics, names and character map data. Specifically, font family name data is handled differently across platforms. For TrueType and OpenType fonts these names are contained in the 'name' table, in name records with name ID 1. Multiple names can be stored for different locales, but Microsoft recommends fonts always include at least a US English version of the name. On Windows, Microsoft made the decision for backwards compatibility to limit this family name to a maximum of four faces; for larger groupings the "preferred family" (name ID 16) or "WWS family" (name ID 21) can be used. Other platforms such as OSX don't have this limitation, so the family name is used to define all possible groupings. Other name table data provides names used to uniquely identify a specific face within a family. The full font name (name ID 4) and the Postscript name (name ID 6) describe a single face uniquely. For example, the bold face of the Gill Sans family has a fullname of "Gill Sans Bold" and a Postscript name of "GillSans-Bold". There can be multiple localized versions of the fullname for a given face, but the Postscript name is always a unique name made from a limited set of ASCII characters. On various platforms, different names are used to search for a font. For example, with the Windows GDI CreateIndirectFont API, either a family or fullname can be used to lookup a face, while on Mac OS X the CTFontCreateWithName API call is used to lookup a given face using the fullname and Postscript name. Under Linux, the fontconfig API allows fonts to be searched using any of these names. In situations where platform API's automatically substitute other font choices, it may be necessary to verify a returned font matches a given name. The weight of a given face can be determined via the usWeightClass field of the OS/2 table or inferred from the style name (name ID 2). Likewise, the width can be determined via the usWidthClass of the OS/2 table or inferred from the style name. For historical reasons related to synthetic bolding at weights 200 or lower with the Windows GDI API, font designers have sometimes skewed values in the OS/2 table to avoid these weights. Rendering complex scripts that use contextual shaping such as Thai, Arabic and Devanagari requires features present only in OpenType or AAT fonts. Currently, complex script rendering is supported on Windows and Linux using OpenType font features while both OpenType and AAT font features are used under Mac OS X.

Security and Privacy Considerations

The ''system-ui'' keyword exposes the operating system's default system UI font to fingerprinting mechanisms.

Acknowledgments

The CSS Working group would like to thank: Peter Constable for assorted language fixes. Optical sizing image prepared by Nick Sherman. Special thanks to Tab Atkins Jr. for providing the text for the section on Font Rendering Controls as well as the section on the 'font-display!!descriptor' descriptor. Special thanks to Ilya Grigorik and David Kuettel for their help in developing these sections.