Overview.bs

<pre class='metadata'>
Group: CSSWG
Shortname: css-fonts
Title: CSS Fonts Module
Level: 3
Status: ED
Work Status: Testing
TR: http://www.w3.org/TR/css-fonts-3/
ED: http://dev.w3.org/csswg/css-fonts/
Editor: John Daggett, Mozilla Japan, jdaggett@mozilla.com
Abstract: This CSS3 module describes how font properties are specified and how font resources are loaded dynamically.  The contents of this specification are a consolidation of content previously divided into <a href="http://www.w3.org/TR/2002/WD-css3-fonts-20020802/">CSS3 Fonts</a> and <a href="http://www.w3.org/TR/2002/WD-css3-webfonts-20020802/">CSS3 Web Fonts</a> modules. The description of font load events was moved into the <a href="http://dev.w3.org/csswg/css-font-load-events/">CSS3 Font Load Events</a> module.
Previous Version: http://www.w3.org/TR/2013/WD-css-fonts-3-20130711/
!Issues List: <a href="http://www.w3.org/Style/CSS/Tracker/products/18">Tracker</a>
!Issues List: <a href="https://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&amp;product=CSS&amp;component=Fonts&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED">Bugzilla</a>
Test Suite: http://test.csswg.org/suites/css3-fonts/nightly-unstable/
At Risk: fallback handling for text decoration in superscript/subscript variant glyphs ('font-variant-position'), 'font-language-override' property
Ignored Terms: font-relative lengths, document language, sub, sup, ident, atkeyword, number, <unicode-range>, domstring, invalidaccesserror
</pre>

<!-- I'm just experimenting here, don't get your bee in a bonnet -->
<script type="text/javascript" src="http://use.typekit.com/xon2bky.js"></script>
<script type="text/javascript">try{Typekit.load();}catch(e){}</script>
<script type="text/javascript">
window.onload = function () {
	if (!("devicePixelRatio" in window && window.devicePixelRatio > 1)) return;
	var i, hiresElements = document.getElementsByClassName("hires");
	for (i = 0; i < hiresElements.length; i++) {
		var h = hiresElements[i];
		if (h.tagName != "IMG") continue;
		var src = h.getAttribute("src");
		var src2x = src.replace(/\.\w+$/, function(m) { return "@2x" + m; });
		h.src = src2x;
	}
}
</script>

<style type="text/css">
body, th, td, h1, h2, h3, h4, h5, h6 {
	font-family: "myriad-pro", sans-serif !important;
}

body {
	padding: 2em 70px 2em 70px;
}

p + p, p.mtb {
	margin-top: 0.8em;
	text-indent: 0px;
}

#bolderlighter {
	width: 40%;
}

#bolderlighter th {
	text-align: center;
}

#fontformats td, #eventhandlers td, #fontformats th, #eventhandlers th {
	padding-right: 2em;
	text-align: left;
}

dd {
	margin-bottom: 1em;
}

#authors dd {
	margin-bottom: 0;
}

#fontstylematchingalg {
	list-style-type: lower-alpha;
}

#fontmatchingalg ul, #fontmatchingalg ol {
	margin-top: 0.8em;
}

#fontmatchingalg li + li {
	margin-top: 0.8em;
}

div.example {
	padding: 1em;
	margin-top: 1em;
}

div.example + div.example {
	margin-top: 2em;
}

div.figure {
	page-break-inside: avoid;
}

pre.prod { white-space: pre-wrap; margin: 1em 0 1em 2em }

div.featex {
	width: 700px;
}

div.featex img {
	margin: auto;
	display: block;
}

span.tag {
	font-family: monospace;
	font-size: 120%;
}

ol ol {
	list-style-type: lower-alpha;
}

.idl-code {
	font-weight: bold;
	color: #c50;
}
</style>

<h2 id="introduction">Introduction</h2>

A font provides a resource containing the visual representation of
characters.  At the simplest level it contains information that maps character
codes to shapes (called glyphs) that represent these characters.  Fonts
sharing a common design style are commonly grouped into font families
classified by a set of standard font properties.  Within a family, the
shape displayed for a given character can vary by stroke weight, slant
or relative width, among others. An individual font face is described by a
unique combination of these properties. For a given range of text, CSS
font properties are used to select a font family and a specific font
face within that family to be used when rendering that text.  As a
simple example, to use the bold form of Helvetica one could use:


<pre>
body {
	font-family: Helvetica;
	font-weight: bold;
}
</pre>

Font resources may be installed locally on the system on which a user
agent is running or downloadable.  For local font resources descriptive
information can be obtained directly from the font resource.  For
downloadable font resources (sometimes referred to as web fonts), the
descriptive information is included with the reference to the font
resource.


Families of fonts typically don't contain a single face for each
possible variation of font properties.  The CSS font selection mechanism
describes how to match a given set of CSS font properties to a single
font face.


<h2 id="typography-background">Typography Background</h2>

<em>This section is non-normative.</em>


Typographic traditions vary across the globe, so there is no unique way
to classify all fonts across languages and cultures.  For even common
Latin letters, wide variations are possible:

<div class="figure"><img alt="variations in glyphs for a single character" src="aaaaaa.png"><p class="caption">One character, many glyph variations</div>

Differences in the anatomy of letterforms is one way to distinguish
fonts.  For Latin fonts, flourishes at the ends of a character's main
strokes, or serifs, can distinguish a font from those without.  Similar
comparisons exist in non-Latin fonts between fonts with tapered strokes
and those using primarily uniform strokes:

<div class="figure"><img alt="serif vs. non-serifs" src="serifvssansserif.png" /><p class="caption">Letterforms with and without serifs</div>

<div class="figure"><img alt="serif vs. non-serifs for japanese" src="minchovsgothic.png" /><p class="caption">Similar groupings for Japanese typefaces</div>

Fonts contain letterforms and the data needed to map characters to
these letterforms. Often this may be a simple one-to-one mapping, but
more complex mappings are also possible. The use of combining diacritic
marks creates many variations for an underlying letterform:

<div class="figure"><img alt="diacritic marks" src="aaaaaa-diacritics.png" /><p class="caption">Variations with diacritic marks</div>

A sequence of characters can be represented by a single glyph known as a ligature:

<div class="figure"><img alt="example of a fi ligature" src="final-ligature.png" /><p class="caption">Ligature example</div>

Visual transformations based on textual context are often
stylistic option in European languages.  They are required to correctly
render languages like Arabic, the lam and alef characters below
<em>must</em> be combined when they exist in sequence:

<div class="figure"><img alt="lam alef ligature" src="lamaleflig.png" /><p class="caption">Required Arabic ligature</div>

The relative complexity of these shaping transformations requires
additional data within the font.

Sets of font faces with various stylistic variations are often
grouped together into font families.  In the simplest case a regular
face is supplemented with bold and italic faces, but much more extensive
groupings are possible.  Variations in the thickness of letterform
strokes, the <dfn>weight</dfn>, and the overall proportions of the letterform,
the <dfn>width</dfn>, are most common. In the example below, each letter uses a
different font face within the Univers font family.  The width used
increases from top to bottom and the weight increases from left to
right:

<div class="figure"><img alt="various width and weight variations within a single family" src="weightwidthvariations.png" /><p class="caption">Weight and width variations within a single font family</div>

Creating fonts that support multiple scripts is a difficult task;
designers need to understand the cultural traditions surrounding the
use of type in different scripts and come up with letterforms that
somehow share a common theme.  Many languages often share a common
script and each of these languages may have noticeable stylistic
differences.  For example, the Arabic script, when used for Persian and
Urdu, exhibits significant and systematic differences in letterforms,
as does Cyrillic when used with languages such as Serbian and
Russian.

The <em>character map</em> of a font defines the mapping of characters
to glyphs for that font. If a document contains characters not
supported by the <a>character maps</a> of the fonts contained in a font
family list, a
user agent may use a <em>system font fallback</em> procedure to locate an
appropriate font that does.  If no appropriate font can be found,
some form of "missing glyph" character will be rendered by the
user agent.  System fallback can occur when the specified list of font families
does not include a font that supports a given character.


Although the <em>character map</em> of a font maps a given character to a
glyph for that character, modern font technologies such as OpenType
and AAT (Apple Advanced Typography) provide ways of mapping a
character to different glyphs based upon feature settings. Fonts in
these formats allow these features to be embedded in the font itself
and controlled by applications.  Common typographic features which can
be specified this way include ligatures, swashes, contextual
alternates, proportional and tabular figures, and automatic fractions,
to list just a few.  For a visual overview of OpenType features, see
the [[OPENTYPE-FONT-GUIDE]].


<h2 id="basic-font-props">Basic Font Properties</h2>

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.

<!-- prop: font-family -->

<h3 id="font-family-prop">Font family: the 'font-family' property</h3>

<pre class="propdef">
Name: font-family
Value: [ <<family-name>> | <<generic-family>> ]#
Initial: depends on user agent
Applies to: all elements
Inherited: yes
Percentages: n/a
Media: visual
Computed value: as specified
Animatable: no
</pre>


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

Note: Designers should note that the CSS definition of font
attributes used for selection are explicitly not intended to define a
font taxonomy.  A type designer's idea of a family may often extend to
a set of faces that vary along axes other than just the standard axes
of weight, width and slope.  A family may extend to include both a set
of serif faces and a set of sans-serif faces or vary along axes that
are unique to that family. The CSS font selection mechanism merely
provides a way to determine the &ldquo;closest&rdquo; substitute when
substitution is necessary.

Unlike other CSS properties, component values are a comma-separated
list indicating alternatives.  A user agent iterates through the list
of family names until it matches an available font that contains a
glyph for the character to be rendered.  This allows for differences
in available fonts across platforms and for differences in the range
of characters supported by individual fonts.

A font family name only specifies a name given to a set of font
faces, it does not specify an individual face.  For example, given the availability
of the fonts below, Futura would match but Futura Medium would not:

<div class="figure"><img alt="family and face names" src="familyvsfacename.png" /><p class="caption">Family and individual face names</div>

Consider the example below:

<div class="example">
<pre>body {
		font-family: Helvetica, Verdana, sans-serif;
}</pre>

If Helvetica is available it will be used when rendering.  If
neither Helvetica nor Verdana is present, then the user-agent-defined
sans serif font will be used.
</div>

There are two types of font family names:

<dl dfn-for="font-family" dfn-type="value">
	<dt><dfn id="family-name-value"><<family-name>></dfn>
	<dd>The name of a font family of choice such as Helvetica or Verdana in the previous example.

	<dt><dfn id="generic-family-value"><<generic-family>></dfn>
	<dd>
		The following generic family keywords are defined: ''serif'', ''sans-serif'', ''cursive'',
		''fantasy'', and ''monospace''. These keywords can be used as a general fallback mechanism
		when an author's desired font choices are not available.  As keywords, they must not
		be quoted. Authors are encouraged to append a generic font family as a last alternative for
		improved robustness.
</dl>

Font family names other than generic families must either be given quoted as <a
href="http://www.w3.org/TR/CSS21/syndata.html#strings">strings,</a>
or unquoted as a sequence of one or more
<a href="http://www.w3.org/TR/CSS21/syndata.html#value-def-identifier">identifiers.</a>
This means most punctuation characters and digits at the start of
each token must be escaped in unquoted font family names.

To illustrate this, the following declarations are invalid:

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

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

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

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

&lt;BODY STYLE="font-family: '21st Century', fantasy">
</pre>

Font family <em>names</em> that happen to be the same as a keyword
value (''inherit'', ''serif'', ''sans-serif'', ''monospace'', ''fantasy'', and
''cursive'') must be quoted to prevent confusion with the keywords with
the same names. The keywords ''initial'' and ''default'' are reserved for
future use and must also be quoted when used as font names. UAs must
not consider these keywords as matching the <var>&lt;family-name&gt;</var>
type.


The precise way a set of fonts are grouped into font families
varies depending upon the platform font management API's.  The
Windows GDI API only allows four faces to be grouped into a family
while the DirectWrite API and API's on OSX and other platforms support
font families with a variety of weights, widths and slopes (see <a
href="#platform-props-to-css">Appendix A</a> for more details).

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

<div class="figure"><img alt="examples of localized family names" src="localizedfamilynames.png" /><p class="caption">Localized family names</div>

The details of localized font family name matching and the
corresponding issues of case sensitivity are described below in the
<a href="#font-family-casing">font matching</a> section.

<h4 id="generic-font-families">Generic font families</h4>

All five generic font families are defined to exist in all CSS
implementations (they need not necessarily map to five distinct actual
fonts). User agents should provide reasonable default choices for the
generic font families, which express the characteristics of each family
as well as possible within the limits allowed by the underlying
technology. User agents are encouraged to allow users to select
alternative choices for the generic fonts.

The syntax of <dfn>&lt;generic-family></dfn> is:

<pre class=prod>&lt;generic-family> = serif | sans-serif | cursive | fantasy | monospace</pre>


<h5 class="no-num no-toc" id='serif-family'><dfn value for="<generic-family>">serif</dfn></h5>

Serif fonts represent the formal text style for a script.
This often means but is not limited to glyphs that have finishing
strokes, flared or tapering ends, or have actual serifed endings
(including slab serifs). Serif fonts are typically
proportionately-spaced. They often display a greater variation between
thick and thin strokes than fonts from the ''sans-serif'' generic font
family. CSS uses the term ''serif'' to apply to a font for any script,
although other names may be more familiar for particular scripts, such
as Mincho (Japanese), Sung, Song or Kai (Chinese), Batang (Korean).
For Arabic, the Naskh style would correspond to ''serif'' more due to
its typographic role rather than its actual design style.
Any font that is so described may be used to represent the
generic ''serif'' family.

<div class="figure"><img alt="sample serif fonts" src="serifexamples.png" /><p class="caption">Sample serif fonts</div>

<h5 class="no-num no-toc" id='sans-serif-family'><dfn value for="<generic-family>">sans-serif</dfn></h5>

Glyphs in sans-serif fonts, as the term is used in CSS, are generally
low contrast (vertical and horizontal stems have the close to the same
thickness) and have stroke
endings that are plain -- without any flaring, cross stroke, or other
ornamentation. Sans-serif fonts are typically
proportionately-spaced. They often have little variation between thick
and thin strokes, compared to fonts from the ''serif'' family. CSS uses
the term ''sans-serif'' to apply to a font for any script, although
other names may be more familiar for particular scripts, such as
Gothic (Japanese), Hei (Chinese), or Gulim (Korean). Any font that
is so described may be used to represent the generic ''sans-serif''
family.

<div class="figure"><img alt="sample sans-serif fonts" src="sansserifexamples.png" /><p class="caption">Sample sans-serif fonts</div>

<h5 class="no-num no-toc" id='cursive-family'><dfn value for="<generic-family>">cursive</dfn></h5>

Glyphs in cursive fonts generally use a more informal script style,
and the result looks more like handwritten pen or brush writing than
printed letterwork. CSS uses the term ''cursive'' to apply to a font for
any script, although other names such as Chancery, Brush, Swing and
Script are also used in font names.

<div class="figure"><img alt="sample cursive fonts" src="cursiveexamples.png" /><p class="caption">Sample cursive fonts</div>

<h5 class="no-num no-toc" id='fantasy-family'><dfn value for="<generic-family>">fantasy</dfn></h5>

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

<div class="figure"><img alt="sample fantasy fonts" src="fantasyexamples.png" /><p class="caption">Sample fantasy fonts</div>

<h5 class="no-num no-toc" id='monospace-family'><dfn value for="<generic-family>">monospace</dfn></h5>

The sole criterion of a monospace font is that all glyphs have the same fixed width.  This is often used
to render samples of computer code.

<div class="figure"><img alt="sample monospace fonts" src="monospaceexamples.png" /><p class="caption">Sample monospace fonts</div>


<!-- prop: font-weight -->

<h3 id="font-weight-prop">Font weight: the 'font-weight' property</h3>

<pre class="propdef">
Name: font-weight
Value: normal | bold | bolder | lighter | 100 | 200 | 300 | 400 | 500 | 600 | 700 | 800 | 900
Initial: normal
Applies to: all elements
Inherited: yes
Percentages: n/a
Media: visual
Computed value: numeric weight value (see description)
Animatable: as font weight
</pre>

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

Values have the following meanings:

<dl dfn-type=value dfn-for=font-weight>
	<dt><dfn>100</dfn>, <dfn>200</dfn>, <dfn>300</dfn>, <dfn>400</dfn>, <dfn>500</dfn>, <dfn>600</dfn>, <dfn>700</dfn>, <dfn>800</dfn>, <dfn>900</dfn>
	<dd>
		These values form an ordered sequence,
		where each number indicates a weight that is at least as dark as its predecessor.
		These roughly correspond to the commonly used weight names below:

		* 100 - Thin
		* 200 - Extra Light (Ultra Light)
		* 300 - Light
		* 400 - Normal
		* 500 - Medium
		* 600 - Semi Bold (Demi Bold)
		* 700 - Bold
		* 800 - Extra Bold (Ultra Bold)
		* 900 - Black (Heavy)

	<dt><dfn>normal</dfn>
	<dd>Same as ''400''.

	<dt><dfn>bold</dfn>
	<dd>Same as ''700''.

	<dt><dfn>bolder</dfn>
	<dd>Specifies a bolder weight than the inherited value.

	<dt><dfn>lighter</dfn>
	<dd>Specifies a lighter weight than the inherited value.
</dl>

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 [[#font-matching-algorithm]] 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:

<div class="figure"><img alt="weight mappings for a family with 400, 700 and 900 weights" src="optimaweights.png" /><p class="caption">Weight mappings for a font family with 400, 700 and 900 weight faces</div>

<div class="figure"><img alt="weight mappings for a family with 300, 600 weights" src="hiraginoweights.png" /><p class="caption">Weight mappings for a font family with 300 and 600 weight faces</div>

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.

<table id="bolderlighter" class="data" summary="Bolder/lighter mappings">
<thead>
<tr>
	<th>Inherited value
	<th>bolder
	<th>lighter


<tbody>
<tr><th>100<td>400<td>100
<tr><th>200<td>400<td>100
<tr><th>300<td>400<td>100
<tr><th>400<td>700<td>100
<tr><th>500<td>700<td>100
<tr><th>600<td>900<td>400
<tr><th>700<td>900<td>400
<tr><th>800<td>900<td>700
<tr><th>900<td>900<td>700

</table>

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.



<h3 id="font-stretch-prop">Font width: the 'font-stretch' property</h3>

<pre class="propdef">
Name: font-stretch
Value: normal | ultra-condensed | extra-condensed | condensed | semi-condensed | semi-expanded | expanded | extra-expanded | ultra-expanded
Initial: normal
Applies to: all elements
Inherited: yes
Percentages: n/a
Media: visual
Computed value: as specified
Animatable: as font stretch
</pre>

The 'font-stretch' property selects a normal,
condensed, or expanded face from a font family. Absolute keyword values
have the following ordering, from narrowest to widest:


<ul dfn-type=value dfn-for=font-stretch>
	<li><dfn>ultra-condensed</dfn>
	<li><dfn>extra-condensed</dfn>
	<li><dfn>condensed</dfn>
	<li><dfn>semi-condensed </dfn>
	<li><dfn>normal</dfn>
	<li><dfn>semi-expanded</dfn>
	<li><dfn>expanded</dfn>
	<li><dfn>extra-expanded</dfn>
	<li><dfn>ultra-expanded</dfn>
</ul>

When a face does not exist
for a given width, normal or condensed values map to a narrower face,
otherwise a wider face.  Conversely, expanded values map to a wider
face, otherwise a narrower face.  The figure below shows how the nine
font-stretch property settings affect font selection for font family
containing a variety of widths, grey indicates a width for which no
face exists and a different width is substituted:


<div class="figure"><img alt="width mappings for a family with condensed, normal and expanded faces" src="universwidths.png" /><p class="caption">Width mappings for a font family with condensed, normal and expanded width faces</div>

<p id="font-stretch-animation">Animation of font stretch:  Font stretch is
interpolated in discrete steps.  The interpolation happens as though the
ordered values are equally spaced real numbers.  The interpolation result
is rounded to the nearest value, with values exactly halfway between two
values rounded towards the later value in the list above.

<h3 id="font-style-prop">Font style: the 'font-style' property</h3>

<pre class="propdef">
Name: font-style
Value: normal | italic | oblique
Initial: normal
Applies to: all elements
Inherited: yes
Percentages: n/a
Media: visual
Computed value: as specifed
Animatable: no
</pre>

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:

<div class="figure"><img alt="artificial sloping vs. real italics" src="realvsfakeitalics.png" /><p class="caption">Artificial sloping versus real italics</div>

Values have the following meanings:

<dl dfn-type=value dfn-for=font-style>
	<dt><dfn>normal</dfn>
	<dd>selects a face that is classified as a normal face, one that is neither italic or obliqued
	<dt><dfn>italic</dfn>
	<dd>selects a font that is labeled as an italic face, or an oblique face if one is not
	<dt><dfn>oblique</dfn>
	<dd>selects a font that is labeled as an oblique face, or an italic face if one is not
</dl>

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.

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

<!-- resolution on the "undefined" nature of synthetics: http://www.w3.org/2013/06/06-css-minutes.html#item03 -->

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 <em>character map</em> assumptions across
faces when implementing support for <em>system font fallback</em>.


<h3 id="font-size-prop">Font size: the 'font-size' property</h3>
<pre class="propdef">
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
Animatable: as length
</pre>

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:

<dl dfn-type=value dfn-for=font-size>
	<dt><dfn type>&lt;absolute-size></dfn>
	<dd> An <<absolute-size>> keyword refers to an entry
in a table of font sizes computed and kept by the user agent. Possible values
are:

	<pre class=prod link-type=value link-for="<absolute-size>">
	<a>xx-small</a> | <a>x-small</a> | <a>small</a> | <a>medium</a> | <a>large</a> | <a>x-large</a> | <a>xx-large</a>
	</pre>

	<dt><dfn type>&lt;relative-size></dfn>

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

	<pre class=prod dfn-type=value dfn-for="<relative-size> font-size">
	<dfn>larger</dfn> | <dfn>smaller</dfn>
	</pre>

	 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.

	<dt><dfn><<length>></dfn>
	<dd>A length value specifies an absolute font size
			(independent of the user agent's font table).
			Negative lengths are illegal.

	<dt><dfn><<percentage>></dfn>
	<dd>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.
</dl>

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.

<table class="data">
	<thead dfn-type=value dfn-for="font-size <absolute-size>">
		<th scope=row><<absolute-size>>
		<th scope=col><dfn>xx-small</dfn>
		<th scope=col><dfn>x-small</dfn>
		<th scope=col><dfn>small</dfn>
		<th scope=col><dfn>medium</dfn>
		<th scope=col><dfn>large</dfn>
		<th scope=col><dfn>x-large</dfn>
		<th scope=col><dfn>xx-large</dfn>
		<th scope=col>

	<tbody>
		<tr>
			<th scope=row>scaling factor
			<td>3/5
			<td>3/4
			<td>8/9
			<td>1
			<td>6/5
			<td>3/2
			<td>2/1
			<td>3/1

		<tr>
			<th scope=row>HTML headings
			<td>h6
			<td>
			<td>h5
			<td>h4
			<td>h3
			<td>h2
			<td>h1
			<td>

		<tr>
			<th scope=row>HTML font sizes
			<td>1
			<td>
			<td>2
			<td>3
			<td>4
			<td>5
			<td>6
			<td>7
</table>

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

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

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

<div class="example">
	Examples:

<pre>p { font-size: 12pt; }
blockquote { font-size: larger }
em { font-size: 150% }
em { font-size: 1.5em }
</pre>
</div>



<h3 id="font-size-adjust-prop">Relative sizing: the 'font-size-adjust' property</h3>

<pre class="propdef">
Name: font-size-adjust
Value: none | <<number>>
Initial: none
Applies to: all elements
Inherited: yes
Percentages: n/a
Media: visual
Computed value: as specified
Animatable: as number
</pre>

For any given font size, the apparent size and legibility of text
varies across fonts. For scripts such as Latin or Cyrillic that
distinguish between upper and lowercase letters, the relative height
of lowercase letters compared to their uppercase counterparts is a
determining factor of legibility. This is commonly referred to as the
<dfn lt="font aspect value" local-lt="aspect value">aspect value</dfn>.
Precisely defined, it is equal to the x-height of a font divided by
the font size.

In situations where font fallback occurs, fallback fonts may not
share the same aspect value as the desired font family and will thus
appear less readable.  The 'font-size-adjust' property is a way to
preserve the readability of text when font fallback occurs.  It does
this by adjusting the font-size so that the x-height is the same
regardless of the font used.

<div class="example">
	The style defined below defines Verdana as the desired font family, but if Verdana is not available Futura or Times
	will be used.

	<pre>
	p {
		font-family: Verdana, Futura, Times;
	}

	&lt;p>Lorem ipsum dolor sit amet, ...&lt;/p>
	</pre>

	Verdana has a relatively high aspect value, lowercase letters are relatively tall compared to uppercase
	letters, so at small sizes text appears legible.  Times has a lower aspect value and so if fallback occurs,
	the text will be less legible at small sizes than Verdana.
</div>

How text rendered in each of these fonts compares is shown below, the columns show text rendered in Verdana, Futura and Times.
The same font-size value is used across cells
within each row and red lines are included to show the differences in x-height.  In the upper half each row is rendered in the same font-size value.  The same is true
for the lower half but in this half the 'font-size-adjust' property is also set so that the actual font size is adjusted
to preserve the x-height across each row.  Note how small text remains relatively legible across each row in the lower half.

<div class="figure"><img alt="text with and without 'font-size-adjust'" src="fontsizeadjust.png" /><p class="caption">Text with and without the use of 'font-size-adjust'</div>

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

<dl dfn-type=value dfn-for=font-size-adjust>
	<dt><dfn>none</dfn>
	<dd>Do not preserve the font's x-height.

	<dt><dfn><<number>></dfn>
	<dd>
		Specifies the <a>aspect value</a> used in the calculation below to calculate the adjusted font size:

		<pre>c  =  ( a / a' ) s </pre>

		where:

		<pre>
		s  =  font-size value
		a  =  <a>aspect value</a> as specified by the 'font-size-adjust' property
		a' =  <a>aspect value</a> of actual font
		c  =  adjusted font-size to use
		</pre>

		This value applies to any font that is selected but in typical usage it should be based
		on the <a>aspect value</a> of the first font in the font-family list.  If this is specified accurately,
		the <tt>(a/a')</tt> term in the formula above is effectively 1 for the first font and no adjustment occurs.
		If the value is specified inaccurately, text rendered using the first font in the family
		list will display differently in older user agents that don't support 'font-size-adjust'.
</dl>

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


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

Authors can calculate the
<a>aspect value</a> for a given font by comparing spans with the same content but
different 'font-size-adjust' properties.  If the same font-size is used, the spans will match when the 'font-size-adjust'
value is accurate for the given font.

<div class="example">
	Two spans with borders are used to determine the <a>aspect value</a> of a font.  The 'font-size' is the same for both spans but the
	'font-size-adjust' property is specified only for the right span.  Starting with a value of 0.5, the aspect
	 value can be adjusted until the borders around the two letters line up.

	<pre>
	p {
		font-family: Futura;
		font-size: 500px;
	}

	span {
		border: solid 1px red;
	}

	.adjust {
		font-size-adjust: 0.5;
	}

	&lt;p>&lt;span>b&lt;/span>&lt;span class="adjust">b&lt;/span>&lt;/p>
	</pre>

	<div class="figure"><img alt="Futura with an aspect value of 0.5" src="beforefontsizeadjust.png" /><p class="caption">Futura with an <a>aspect value</a> of 0.5</div>

	The box on the right is a bit bigger than the one on the left, so the <a>aspect value</a> of this font is something less than 0.5.
	Adjust the value until the boxes align.
</div>

<h3 id="font-prop">Shorthand font property: the 'font' property</h3>

<pre class="propdef shorthand">
Name: font
Value: [ [ <<'font-style'>> || <<font-variant-css21>> || <<'font-weight'>> || <<'font-stretch'>> ]?
Value:   <<'font-size'>> [ / <<'line-height'>> ]? <<'font-family'>> ]
Value: | caption | icon | menu | message-box | small-caption | status-bar
</pre>

The 'font' property is, except as
described below, a shorthand property for setting
'font-style',
'font-variant',
'font-weight',
'font-stretch',
'font-size',
'line-height',
and 'font-family' at the same place in the stylesheet.
Values for the 'font-variant'
property may also be included, but only those supported in CSS 2.1; none
of the 'font-variant' values added in this specification can be used in
the 'font' shorthand:

<pre class="prod"><dfn>&lt;font-variant-css21></dfn> = [ <dfn value for="<font-variant-css21> font">normal</dfn> | <dfn value for="<font-variant-css21> font">small-caps</dfn> ]</pre>

Additionally, it is a shorthand for
'font-size-adjust',
'font-kerning',
and 'font-language-override',
but as these cannot be specified in the syntax,
it merely resets these to their initial values.

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

<div class="example">
	Examples:

	<pre>
	p { font: 12pt/14pt sans-serif }
	p { font: 80% sans-serif }
	p { font: x-large/110% &quot;new century schoolbook&quot;, serif }
	p { font: bold italic large Palatino, serif }
	p { font: normal small-caps 120%/120% fantasy }
	p { font: condensed oblique 12pt &quot;Helvetica Neue&quot;, serif; }
	</pre>

	In the second rule, the font size percentage value (''80%'') refers
	to the computed 'font-size' of the parent element. In the third rule, the line
	height percentage (''110%'') refers to the font size of the element
	itself.

	The first three rules do not specify the 'font-variant'
	and 'font-weight' explicitly, so these properties
	receive their initial values (''font-variant/normal''). Notice that the font family
	name "new century schoolbook", which contains spaces, is enclosed in
	quotes. The fourth rule sets the
	'font-weight' to ''bold'', the
	'font-style' to ''italic'', and implicitly sets
	'font-variant' to ''font-variant/normal''.


	The fifth rule sets the 'font-variant' (''small-caps''),
	the 'font-size' (120% of the parent's font size),
	the 'line-height' (120% of the font size)
	and the 'font-family' (''fantasy'').
	It follows that the keyword ''font-style/normal'' applies to the two
	remaining properties: 'font-style' and 'font-weight'.


	The sixth rule sets the 'font-style', 'font-stretch', 'font-size', and 'font-family',
	the other font properties being set to their initial values.
</div>

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

<pre class="example">
p {
	font: 80% sans-serif;   /* for older user agents */
	font: condensed 80% sans-serif;
}
</pre>

The following values refer to system fonts:

<dl dfn-for="font" dfn-type=value>
	<dt><dfn>caption</dfn>
	<dd>The font used for captioned controls (e.g., buttons, drop-downs, etc.).
	<dt><dfn>icon</dfn>
	<dd>The font used to label icons.
	<dt><dfn>menu</dfn>
	<dd>The font used in menus (e.g., dropdown menus and menu lists).
	<dt><dfn>message-box</dfn>
	<dd>The font used in dialog boxes.
	<dt><dfn>small-caption</dfn>
	<dd>The font used for labeling small controls.
	<dt><dfn>status-bar</dfn>
	<dd>The font used in window status bars.
</dl>

System fonts may only be set as a whole; that is, the font
family, size, weight, style, etc. are all set at the same time.
These values may then be altered individually if desired.  If no
font with the indicated characteristics exists on a given platform,
the user agent should either intelligently substitute (e.g., a smaller
version of the ''caption'' font might be used for the ''small-caption''
font), or substitute a user agent default font. As for regular fonts,
if, for a system font, any of the individual properties are not part
of the operating system's available user preferences, those properties
should be set to their initial values.

That is why this property is "almost" a shorthand property: system
fonts can only be specified with this property, not with
'font-family' itself, so 'font'
allows authors to do more than the
sum of its subproperties. However, the individual properties such as
'font-weight' are still given values
taken from the system font, which can be independently varied.

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

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

<div class="example">
	Examples:

	<pre>
	button { font: 300 italic 1.3em/1.7em &quot;FB Armada&quot;, sans-serif }
	button p { font: menu }
	button p em { font-weight: bolder }
	</pre>

	If the font used for dropdown menus on a particular system
	happened to be, for example, 9-point Charcoal, with a weight of 600, then P
	elements that were descendants of BUTTON would be displayed as if
	this rule were in effect:

	<pre>button p { font: 600 9pt Charcoal } </pre>

	Because the 'font' shorthand resets to its initial value
	any property not explicitly given a value, this has the same effect as
	this declaration:

	<pre>
	button p {
		font-style: normal;
		font-variant: normal;
		font-weight: 600;
		font-size: 9pt;
		line-height: normal;
		font-family: Charcoal
	}
	</pre>
</div>


<h3 id="font-synthesis-prop">Controlling synthetic faces: the 'font-synthesis' property</h3>

<pre class="propdef">
Name: font-synthesis
Value: none | [ weight || style ]
Initial: weight style
Applies to: all elements
Inherited: yes
Percentages: n/a
Media: visual
Computed value: as specified
Animatable: no
</pre>

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

<dl dfn-type=value dfn-for=font-synthesis>
	<dt><dfn>weight</dfn>
	<dd>
		If a 'font-weight' is requested that the font family does not contain,
		the user agent may synthesize the requested weight from the weights that do exist in the font family.

		If this is not specified, the user agent must <em>not</em> synthesize missing weights.

	<dt><dfn>style</dfn>
	<dd>
		If a 'font-style' is requested that the font family does not contain,
		the user agent may synthesize the requested style from the ''font-style/normal'' face in the font family.

		If this is not specified, the user agent must <em>not</em> synthesize missing styles.

	<dt><dfn>none</dfn>
	<dd>
		The user agent must not synthesize any missing faces.
</dl>

Note: When a face is missing (and not synthesized),
font fallback occurs.

<div class="example">
	The style rule below disables the use of synthetically obliqued Arabic:

	<pre>*:lang(ar) { font-synthesis: none; }</pre>
</div>

<h2 id="font-resources">Font Resources</h2>

<h3 id="font-face-rule">The <dfn>@font-face</dfn> rule</h3>

The ''@font-face'' rule allows for linking to fonts that are
automatically fetched and activated when needed.  This allows authors to select
a font that closely matches the design goals for a given page
rather than limiting the font choice to a set of fonts available
on a given platform.  A set of font descriptors define the location of a font
resource, either locally or externally, along with the style characteristics of
an individual face.  Multiple ''@font-face'' rules can be used to construct
font families with a variety of faces.  Using CSS font matching rules, a
user agent can selectively download only those faces that are needed for
a given piece of text.


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

<pre>
<dfn>font_face_rule</dfn>
	: <a>FONT_FACE_SYM</a> <a href="http://www.w3.org/TR/CSS21/grammar.html#scanner">S</a>* '{' <a href="http://www.w3.org/TR/CSS21/grammar.html#scanner">S</a>* <a>descriptor_declaration</a>? [ ';' <a href="http://www.w3.org/TR/CSS21/grammar.html#scanner">S</a>* <a>descriptor_declaration</a>? ]* '}' <a href="http://www.w3.org/TR/CSS21/grammar.html#scanner">S</a>*
	;

<dfn>descriptor_declaration</dfn>
	: <a href="http://www.w3.org/TR/CSS21/grammar.html#grammar">property</a> ':' <a href="http://www.w3.org/TR/CSS21/grammar.html#scanner">S</a>* <a href="http://www.w3.org/TR/CSS21/grammar.html#grammar">expr</a>
	;
</pre>

The following new definitions are introduced:

<pre>
-    -|\\0{0,4}2d(\r\n|[ \t\r\n\f])?
F    f|\\0{0,4}(46|66)(\r\n|[ \t\r\n\f])?</pre>

The following new token is introduced:

<pre>@{F}{O}{N}{T}{-}{F}{A}{C}{E} {return <dfn>FONT_FACE_SYM</dfn>;}</pre>

Each ''@font-face''
rule specifies a value for every font descriptor, either implicitly or
explicitly. Those not given explicit values in the rule take the initial
value listed with each descriptor in this specification. These
descriptors apply solely within the context of the ''@font-face'' rule in
which they are defined, and do not apply to document language elements.
There is no notion of which elements the descriptors apply to or whether
the values are inherited by child elements.  When a given descriptor occurs
multiple times in a given ''@font-face'' rule, only the last
descriptor declaration is used and all prior declarations for that
descriptor are ignored.

<div class="example">
	To use a downloadable font called Gentium:

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

	p { font-family: Gentium, serif; }
	</pre>

	The user agent will download Gentium and use it when rendering text
	within paragraph elements.  If for some reason the site serving the font
	is unavailable, the default serif font will be used.
</div>

A given set of ''@font-face'' rules define a set of fonts
available for use within the documents that contain these rules.
When font matching is done, fonts defined using these rules
are considered before other available fonts on a system.

Downloaded fonts are only available to documents that reference them.
The process of activating these fonts must not make them available to
other applications or to documents that don't directly link to the same
font. User agent implementers might consider it convenient to use
downloaded fonts when rendering characters in other documents for which no
other available font exists as part of the <em>system font fallback</em> procedure.
However, this would cause a security leak since the contents of one page would be
able to affect other pages, something an attacker could use as an attack
vector.  These restrictions do not affect caching behavior, fonts are
cached the same way other web resources are cached.


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

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


<h3 id="font-family-desc">Font family: the ''@font-face/font-family'' descriptor</h3>

<pre class="descdef">
Name: font-family
For: @font-face
Value: <<family-name>>
Initial: n/a (required)
</pre>

This descriptor defines the font family name that will be used in
all CSS font family name matching.  It is required for the ''@font-face''
rule to be valid. It overrides the font family names contained in the
underlying font data. If the font family name is the same as a font
family available in a given user's environment, it effectively hides
the underlying font for documents that use the stylesheet.  This
permits a web author to freely choose font-family names without
worrying about conflicts with font family names present in a given
user's environment. Likewise, platform substitutions for a given font
family name must not be used.

<h3 id="src-desc">Font reference: the ''@font-face/src'' descriptor</h3>

<pre class="descdef">
Name: src
For: @font-face
Value: [ <<url>> format(<<string>>#)? | local(<<family-name>>) ]#
Initial: n/a (required)
</pre>

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

<pre>
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" */
</pre>

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.

<pre>
/* 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");
}
</pre>

Format strings defined by this specification:


<table class="data" id="fontformats">
	<thead>
		<tr>
			<th>String
			<th>Font Format
			<th>Common extensions
	<tbody>
		<tr>
			<th>"woff"
			<td><a href="http://www.w3.org/TR/WOFF/">WOFF (Web Open Font Format)</a>
			<td>.woff
		<tr>
			<th>"truetype"
			<td><a href="http://www.microsoft.com/typography/otspec/default.htm">TrueType</a>
			<td>.ttf
		<tr>
			<th>"opentype"
			<td><a href="http://www.microsoft.com/typography/otspec/default.htm">OpenType</a>
			<td>.ttf, .otf
		<tr>
			<th>"embedded-opentype"
			<td><a href="http://www.w3.org/Submission/2008/SUBM-EOT-20080305/">Embedded OpenType</a>
			<td>.eot
		<tr>
			<th>"svg"
			<td><a href="http://www.w3.org/TR/SVG/fonts.html">SVG Font</a>
			<td>.svg, .svgz
</table>

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 <a href="#platform-props-to-css">Appendix A</a> for more background on this).


When authors would prefer to use a locally available
copy of a given font and download it if it's not, <dfn type=function for="@font-face/src">local()</dfn>
can be used. The locally-installed <<family-name>>
argument to ''local()'' is a format-specific string that
uniquely identifies a single font face within a larger family.
Like its use in 'font-family',
<<family-name>> can be a quoted string,
or a series of unquoted identifiers which are converted to a face name
by concatenating them separated by a space.

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

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.

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

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
<a href="http://www.microsoft.com/typography/otspec/name.htm">name table</a>,
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 <a href="http://www.microsoft.com/typography/otspec/recom.htm">all fonts
minimally include US English names</a>). 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.


<div class="example">
	Use a local font or reference an SVG font in another document:

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

	Create an alias for local Japanese fonts on different platforms:

	<pre>
	@font-face {
		font-family: jpgothic;
		src: local(HiraKakuPro-W3), local(Meiryo), local(IPAPGothic);
	}
	</pre>

	Reference a font face that cannot be matched within a larger family:

	<pre>
	@font-face {
		font-family: Hoefler Text Ornaments;
		/* has the same font properties as Hoefler Text Regular */
		src: local(HoeflerText-Ornaments);
	}
	</pre>

	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:

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

	h2 { font-family: SectionHeader, serif; }
	</pre>

	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:

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

<h3 id="font-prop-desc">
Font property descriptors: the ''@font-face/font-style'', ''@font-face/font-weight'', ''@font-face/font-stretch'' descriptors</h3>

<pre class="descdef">
Name: font-style
For: @font-face
Value: <span dfn-type=value dfn-for="@font-face/font-style"><dfn>normal</dfn> | <dfn>italic</dfn> | <dfn>oblique</dfn></span>
Initial: normal
</pre>

<pre class="descdef">
Name: font-weight
For: @font-face
Value: normal | bold | 100 | 200 | 300 | 400 | 500 | 600 | 700 | 800 | 900
Initial: normal
</pre>

<pre class="descdef">
Name: font-stretch
For: @font-face
Value: normal | ultra-condensed | extra-condensed | condensed | semi-condensed | semi-expanded | expanded | extra-expanded | ultra-expanded
Initial: normal
</pre>

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

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.

<div class="example">
	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:

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

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

	<div class="figure"><img alt="regular face display" src="fiddlesticks-regular.png" width="373" /></div>

	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:

	<div class="figure"><img alt="synthetic italics display" src="fiddlesticks-synitalics.png" width="373" /></div>

	Now consider a family for which an actual italic face is defined:
	<pre>
	@font-face {
		font-family: BaskervilleFull;
		src: url(baskerville-regular.woff);
	}

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

	The second ''@font-face'' rule defines the font resource
	<code>baskerville-italic.woff</code> 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:

	<div class="figure"><img alt="real italics display" src="fiddlesticks-italics.png" width="373" /></div>

	See [[#font-style-matching]]
	for more complete details of the process used to select a particular
	face within a font family.
</div>

<h3 id="unicode-range-desc">Character range: the ''@font-face/unicode-range'' descriptor</h3>

<pre class="descdef">
Name: unicode-range
For: @font-face
Value: <<unicode-range>>#
Initial: U+0-10FFFF
</pre>

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

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

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

<h3 id="composite-fonts">Using character ranges to define composite fonts</h3>

Multiple ''@font-face'' rules with different unicode ranges for the same
family and style descriptor values can be used to create composite fonts
that mix the glyphs from different fonts for different scripts.  This
can be used to combine fonts that only contain glyphs for a single
script (e.g. Latin, Greek, Cyrillic) or it can be used by authors as a
way of segmenting a font into fonts for commonly used characters and
less frequently used characters. Since the user agent will only pull
down the fonts it needs this helps reduce page bandwidth.

If the unicode ranges overlap for a set of ''@font-face'' rules with the
same family and style descriptor values, the rules are ordered in the
reverse order they were defined; the last rule defined is the first to
be checked for a given character.

Example ranges for specific languages or characters:

<dl>
	<dt>unicode-range: U+A5;
	<dd>a single code point, the yen/yuan symbol

	<dt>unicode-range: U+0-7F;
	<dd>code range for basic ASCII characters

	<dt>unicode-range: U+590-5ff;
	<dd>code range for Hebrew characters

	<dt>unicode-range: U+A5, U+4E00-9FFF, U+30??, U+FF00-FF9F;
	<dd>code range for Japanese kanji, hiragana and katakana characters plus yen/yuan symbol
</dl>

<div class="example">
	The BBC provides news services in a wide variety of languages, many
	that are not well supported across all platforms. Using an ''@font-face''
	rule, the BBC could provide a font for any of these languages, as it
	already does via a manual font download.
	<pre>
	@font-face {
		font-family: BBCBengali;
		src: url(fonts/BBCBengali.woff) format("woff");
		unicode-range: U+00-FF, U+980-9FF;
	}
	</pre>
</div>

<div class="example">
	Technical documents often require a wide range of symbols.  The STIX
	Fonts project is one project aimed at providing fonts to support a wide
	range of technical typesetting in a standardized way.  The example below
	shows the use of a font that provides glyphs for many of the
	mathematical and technical symbol ranges within Unicode:

	<pre>
	@font-face {
		font-family: STIXGeneral;
		src: local(STIXGeneral), url(/stixfonts/STIXGeneral.otf);
		unicode-range: U+000-49F, U+2000-27FF, U+2900-2BFF, U+1D400-1D7FF;
	}
	</pre>
</div>

<div class="example">
	This example shows how an author can override the glyphs used for
	Latin characters in a Japanese font with glyphs from a different font.
	The first rule specifies no range so it defaults to the entire range.
	The range specified in the second rule overlaps but takes precedence
	because it is defined later.

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

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

<div class="example">
	Consider a family constructed to optimize bandwidth by separating out
	Latin, Japanese and other characters into different font files:

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

	/* Japanese glyphs - size: 1.2MB */
	@font-face {
		font-family: DroidSans;
		src: url(DroidSansJapanese.woff);
		unicode-range: U+3000-9FFF, U+ff??;
	}

	/* Latin, Greek, Cyrillic along with some
		 punctuation and symbols - size: 190KB */
	@font-face {
		font-family: DroidSans;
		src: url(DroidSans.woff);
		unicode-range: U+000-5FF, U+1e00-1fff, U+2000-2300;
	}
	</pre>

	For simple Latin text, only the font for Latin characters is downloaded:

	<pre>
	body { font-family: DroidSans; }

	&lt;p>This is that&lt;/p>
	</pre>

	In this case the user agent first checks the unicode-range for the
	font containing Latin characters (DroidSans.woff).  Since all the
	characters above are in the range U+0-5FF, the user agent downloads the
	font and renders the text with that font.


	Next, consider text that makes use of an arrow character (&#x21e8;):

	<pre>
	&lt;p>This &amp;#x21e8; that&lt;p>
	</pre>

	The user agent again first checks the unicode-range of the font
	containing Latin characters.  Since U+2000-2300 includes the arrow
	code point (U+21E8), the user agent downloads the font.  For this
	character however the Latin font does not have a matching glyph, so the
	effective unicode-range used for font matching excludes this code point.
	Next, the user agent evaluates the Japanese font.  The unicode-range for
	the Japanese font, U+3000-9FFF and U+ff??, does not include U+21E8, so
	the user agent does not download the Japanese font.
	Next the fallback font is considered.  The ''@font-face'' rule for the
	fallback font does not define unicode-range so its value defaults to
	the range of all Unicode code points. The fallback font is downloaded and
	used to render the arrow character.
</div>

<h3 id="font-rend-desc">Font features: the ''@font-face/font-variant'' and ''@font-face/font-feature-settings'' descriptors</h3>

<pre class="descdef">
Name: font-variant
For: @font-face
Value: normal | none |
Value: [
Value:   <<common-lig-values>> || <<discretionary-lig-values>> || <<historical-lig-values>> || <<contextual-alt-values>> ||
Value:   stylistic(<<feature-value-name>>) || historical-forms || styleset(<<feature-value-name>>#) ||
Value:   character-variant(<<feature-value-name>>#) || swash(<<feature-value-name>>) || ornaments(<<feature-value-name>>) ||
Value:   annotation(<<feature-value-name>>) || [ small-caps | all-small-caps | petite-caps | all-petite-caps | unicase | titling-caps ] ||
Value:   <<numeric-figure-values>> || <<numeric-spacing-values>> || <<numeric-fraction-values>> || ordinal || slashed-zero ||
Value:   <<east-asian-variant-values>> || <<east-asian-width-values>> || ruby
Value: ]
Initial: normal
</pre>

<pre class="descdef">
Name: font-feature-settings
For: @font-face
Value: normal | <<feature-tag-value>>#
Initial: normal
</pre>

These descriptors define initial settings that apply when the font defined by
an ''@font-face'' rule is rendered.  They do not affect font selection.
Values are identical to those defined for the corresponding
'font-variant' and 'font-feature-settings' properties.  When multiple font
feature descriptors or properties are used, the cumulative effect on
text rendering is detailed in [[#font-feature-resolution]].
In cases where specific values define synthesized fallback for certain
'font-variant' subproperties, the same synthesized fallback
applies when used within those values are used with the
'font-variant' descriptor.


<h3 id="font-face-loading">Font loading guidelines</h3>

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


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

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


<h3 id="font-fetching-requirements">Font fetching requirements
<span id="same-origin-restriction"></span>
<span id="allowing-cross-origin-font-loading"></span>
</h3>

<!-- TPAC 2011 Resolution to require same-origin restriction for loading fonts:
	http://lists.w3.org/Archives/Public/www-style/2011Nov/0711.html
	http://www.w3.org/2011/10/31-webapps-minutes.html#item02
-->

For font loads, user agents must use the
<a href="http://www.w3.org/TR/html5/infrastructure.html#cors-enabled-fetch">potentially CORS-enabled fetch</a>
method defined by the [[!HTML5]] specification for URL's defined
within @font-face rules. When fetching, user agents must use
"Anonymous" mode, set the referrer source to the stylesheet's URL and
set the origin to the URL of the containing document.

Note: The implications of this for authors are that fonts
will typically not be loaded cross-origin unless authors specifically
takes steps to permit cross-origin loads. Sites can explicitly allow
cross-site loading of font data using the <code>Access-Control-Allow-Origin</code>
HTTP header.  For other schemes, no explicit mechanism to allow
cross-origin loading, beyond what is permitted by the
<a href="http://www.w3.org/TR/html5/infrastructure.html#cors-enabled-fetch">potentially CORS-enabled fetch</a>
method, is defined or required.

<div class="example">
	For the examples given below, assume that a document is located at
	<code>http://example.com/page.html</code> and all URL's link to valid
	font resources supported by the user agent.

	Fonts defined with the 'src' descriptor values below will be loaded:

	<pre>
	/* 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);
	</pre>

	Fonts defined with the 'src' descriptor values below will fail to load:

	<pre>
	/* 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);
	</pre>
</div>

<h2 id="font-matching-algorithm">Font Matching Algorithm</h2>

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.

<h3 id="font-family-casing">Case sensitivity of font family names</h3>

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

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

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

<h3 id="font-style-matching">Matching font styles</h3>

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 <dfn export>character map</dfn> of the font, data
which maps characters to the default glyph for that character. A font
is considered to <dfn>support</dfn> a given character if (1) the
character is contained in the font's <em>character map</em> 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 <a>character map</a> but lack the shaping information (e.g.
<a href="http://www.microsoft.com/typography/otspec/ttochap1.htm">OpenType layout tables</a> or
<a href="http://scripts.sil.org/cms/scripts/page.php?site_id=projects&amp;item_id=graphite_techAbout">Graphite tables</a>)
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 [[#cluster-matching]].

For this procedure, the <dfn export>default face</dfn> 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.

<div id="fontmatchingalg">
	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
		<a href="#font-family-casing">case-insensitive comparison</a> 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.  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 <dfn>composite face</dfn> for this step:

		<div id="fontstylematchingalg">
		1. 'font-stretch' is tried
			first. If the matching set contains faces with width values
			matching the 'font-stretch' value, faces with other width
			values are removed from the matching set. If there is no face
			that exactly matches the width value the nearest width is
			used instead.  If the value of 'font-stretch' is ''font-stretch/normal'' or
			one of the condensed values, narrower width values are
			checked first, then wider values.  If the value of
			'font-stretch' is one of the expanded values, wider values
			are checked first, followed by narrower values. Once the
			closest matching width has been determined by this process,
			faces with other widths 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 ''font-style/normal'',
			normal faces are checked first, then oblique faces, then
			italic faces.  Faces with other style values 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. 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, so it will always reduce the matching set to a single font
			face. 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 weights of faces
			in the matching set after the steps above, if the desired
			weight is available that face matches.  Otherwise, a weight
			is chosen using the rules below:

				* If the desired weight is less than 400, 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 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.
				* If the desired weight is 400, 500 is checked first and then
					the rule for desired weights less than 400 is used.
				* If the desired weight is 500, 400 is checked first and then
					the rule for desired weights less than 400 is used.

		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.

	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 <a>effective character map</a>
			supports the character in question, select that font.

		When the matched face is a <a>composite face</a>, user agents must use
		the procedure above on each of the faces in the <a>composite face</a> 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
		<a>default face</a> 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.

		<!-- resolution on the above: http://lists.w3.org/Archives/Public/www-style/2012Nov/0292.html -->

	7. If there are no more font families to be evaluated
		and no matching face has been found,
		then the user agent performs a <dfn>system font fallback</dfn> 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 <a href="http://en.wikipedia.org/wiki/Last_resort_font">Last Resort Font</a>)
		or using the missing character glyph from a default font.
</div>

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 <dfn export>first available font</dfn>, used in the definition of
<a>font-relative lengths</a>
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).

<h3 id="cluster-matching">Cluster matching</h3>

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

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

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 <var>b + c1 + c2 &hellip;</var> 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 <a>supports</a> 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 <var>c1</var> is a variation selector, system fallback must be used
		to find a font that <a>supports</a> the full sequence of <var>b + c1</var>.
		If no font on the system <a>supports</a> the full sequence, match the single
		character <var>b</var> 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 <a>supports</a> 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
	<a>supported</a> by a font in the font list and attempt to match the remaining
	combining characters separately using the rules for single characters.

<h3 id="char-handling-issues">Character handling issues</h3>

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

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

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

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

<h3 id="font-matching-changes">Font matching changes since CSS 2.1</h3>

The algorithm above is different from CSS 2.1 in a number of key places.
These changes were made to better reflect actual font matching behavior
across user agent implementations.

Differences compared to the font matching algorithm in CSS 2.1:

* The algorithm includes font-stretch matching.
* All possible font-style matching scenarios are delineated.
* Small-caps fonts are not matched as part of the font matching process, they are now handled via font features.
* Unicode variation selector matching is required.
* Cluster sequences are matched as a unit.

<h3 id="font-matching-examples">Font matching examples</h3>

<div class="example">
	It's useful to note that the CSS selector syntax  may be used to
	create language-sensitive typography. For example, some Chinese and
	Japanese characters are unified to have the same Unicode code point,
	although the abstract glyphs are not the same in the two languages.

	<pre>
	:lang(ja) { font: 900 14pt/16pt "Heisei Mincho W9", serif; }
	*:lang(zh-Hant-TW) { font: 800 14pt/16.5pt "Li Sung", serif; }
	</pre>

	This selects any element that has the given language--
	Japanese or Traditional Chinese as used in Taiwan--
	and uses the appropriate font.
</div>

<h2 id="font-rend-props">Font Feature Properties</h2>

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

<h3 id="glyph-selection-positioning">Glyph selection and positioning</h3>

Simple fonts used for displaying Latin text use a very basic
processing model. Fonts contain a <a>character map</a> which maps each
character to a glyph for that character.  Glyphs for subsequent
characters are simply placed one after the other along a run of text.  Modern font
formats such as OpenType and AAT (Apple Advanced Typography) use a
richer processing model. The glyph for a given character can be
chosen and positioned not just based on the codepoint of the character
itself, but also on adjacent characters as well as the language,
script, and features enabled for the text.  Font features may be
required for specific scripts, or recommended as enabled by default or
they might be stylistic features meant to be used under author
control.

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

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

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

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

<h3 id="language-specific-support">Language-specific display</h3>

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

<div class="featex"><img alt="language specific forms, spanish" src="locl-1.png"></div>
<div class="featex"><img alt="language specific forms, italian" src="locl-2.png"></div>
<div class="featex"><img alt="language specific forms, french" src="locl-3.png"></div>

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

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


<h3 id="font-kerning-prop">Kerning: the 'font-kerning' property</h3>

<pre class="propdef">
Name: font-kerning
Value: auto | normal | none
Initial: auto
Inherited: yes
Percentages: n/a
Computed value: as specified
</pre>

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

<dl dfn-type=value dfn-for=font-kerning>
	<dt><dfn>auto</dfn>
	<dd>Specifies that kerning is applied at the discretion of the user agent
	<dt><dfn>normal</dfn>
	<dd>Specifies that kerning is applied
	<dt><dfn>none</dfn>
	<dd>Specifies that kerning is not applied
</dl>

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

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


<h3 id="font-variant-ligatures-prop">Ligatures: the 'font-variant-ligatures' property</h3>

<pre class="propdef">
Name: font-variant-ligatures
Value: normal | none | <<common-lig-values>> | <<discretionary-lig-values>> | <<historical-lig-values>> | <<contextual-alt-values>>
Initial: normal
Inherited: yes
Computed value: as specified
</pre>

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

<pre class="prod">
<dfn>&lt;common-lig-values></dfn>        = common-ligatures | no-common-ligatures
<dfn>&lt;discretionary-lig-values></dfn> = discretionary-ligatures | no-discretionary-ligatures
<dfn>&lt;historical-lig-values></dfn>    = historical-ligatures | no-historical-ligatures
<dfn>&lt;contextual-alt-values></dfn>    = contextual | no-contextual
</pre>

Individual values have the following meanings:

<dl dfn-type=value>
	<dt><dfn for="font-variant-ligatures">normal</dfn>
	<dd>
		Specifies that common default features are enabled, as described in [[#font-feature-resolution]].
		For OpenType fonts, common ligatures and contextual forms are on by default,
		discretionary and historical ligatures are not.

	<dt><dfn for="font-variant-ligatures">none</dfn>
	<dd>
		Specifies that all types of ligatures and contextual forms covered by this property are
		explicitly disabled.  In situations where ligatures are not considered necessary, this may
		improve the speed of text rendering.

	<dt><dfn for="font-variant-ligatures <common-lig-values>">common-ligatures</dfn>
	<dd>
		Enables display of common ligatures (OpenType features: <code>liga</code>, <code>clig</code>).  For OpenType fonts,
		common ligatures are enabled by default.

		<div class="featex"><img alt="common ligature example" src="liga.png"></div>

	<dt><dfn for="font-variant-ligatures <common-lig-values>">no-common-ligatures</dfn>
	<dd>
		Disables display of common ligatures (OpenType features: <code>liga</code>, <code>clig</code>).

	<dt><dfn for="font-variant-ligatures <discretionary-lig-values>">discretionary-ligatures</dfn>
	<dd>
		Enables display of discretionary ligatures (OpenType feature: <code>dlig</code>).  Which ligatures
		are discretionary or optional is decided by the type designer, so authors will need to refer to
		the documentation of a given font to understand which ligatures are considered discretionary.

		<div class="featex"><img alt="discretionary ligature example" src="dlig.png"></div>

	<dt><dfn for="font-variant-ligatures <discretionary-lig-values>">no-discretionary-ligatures</dfn>
	<dd>
		Disables display of discretionary ligatures (OpenType feature: <code>dlig</code>).

	<dt><dfn for="font-variant-ligatures <historical-lig-values>">historical-ligatures</dfn>
	<dd>
		Enables display of historical ligatures (OpenType feature: <code>hlig</code>).

		<div class="featex"><img alt="historical ligature example" src="hlig.png"></div>

	<dt><dfn for="font-variant-ligatures <historical-lig-values>">no-historical-ligatures</dfn>
	<dd>
		Disables display of historical ligatures (OpenType feature: <code>hlig</code>).

	<dt><dfn for="font-variant-ligatures <contextual-alt-values>">contextual</dfn>
	<dd>
		Enables display of contextual alternates (OpenType feature: <code>calt</code>).  Although
		not strictly a ligature feature, like ligatures this feature is commonly used to harmonize
		the shapes of glyphs with the surrounding context.  For OpenType fonts, this feature is
		on by default.

		<div class="featex"><img alt="contextual alternate example" src="calt.png"></div>

	<dt><dfn for="font-variant-ligatures <contextual-alt-values>">no-contextual</dfn>
	<dd>
		Disables display of contextual alternates (OpenType feature: <code>calt</code>).
</dl>

Required ligatures, needed for correctly rendering complex scripts, are
not affected by the settings above, including ''font-variant-ligatures/none'' (OpenType feature: <code>rlig</code>).


<h3 id="font-variant-position-prop">Subscript and superscript forms: the 'font-variant-position' property</h3>

<pre class="propdef">
Name: font-variant-position
Value: normal | sub | super
Initial: normal
Inherited: yes
</pre>

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

<div class="figure"><img alt="comparison between real subscript glyphs and synthesized ones" src="realsubscripts.png" /><p class="caption">Subscript glyphs (top) vs. typical synthesized subscripts (bottom)</div>

Individual values have the following meanings:

<dl dfn-type=value dfn-for=font-variant-position>
	<dt><dfn>normal</dfn>
	<dd>None of the features listed below are enabled.
	<dt><dfn>sub</dfn>
	<dd>Enables display of subscript variants (OpenType feature: <code>subs</code>).
	<dt><dfn>super</dfn>
	<dd>Enables display of superscript variants (OpenType feature: <code>sups</code>).
</dl>

Because of the semantic nature of subscripts and superscripts, when
the value is either ''sub'' or ''super'' for a given contiguous run of
text, if a variant glyph is not available for all the characters in
the run, simulated glyphs must be synthesized for all characters using
reduced forms of the glyphs that would be used without this feature
applied. This is done per run to avoid a mixture of variant glyphs and
synthesized ones that would not align correctly. In the case of
OpenType fonts that lack subscript or superscript glyphs for a given
character, user agents must use the appropriate subscript and
superscript metrics specified in the selected font's
<a href="http://www.microsoft.com/typography/otspec/os2.htm#subxs">OS/2 table</a>
[[!OPENTYPE]] to calculate the size and offset of the synthesized substitutes.


<div class="figure"><img alt="alternate superscripts vs. glyphs synthesized using superscript metrics" src="superscript-alt-synth.png" /><p class="caption">Superscript alternate glyph (left), synthesized superscript glyphs (middle),  and incorrect mixture of the two (right)</div>

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

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

Authors should note that fonts typically only provide subscript and
superscript glyphs for a subset of all characters supported by the
font.  For example, while subscript and superscript glyphs are often
available for Latin numbers, glyphs for punctuation and letter
characters are less frequently provided.  The synthetic fallback rules
defined for this property assure that subscripts and superscripts will
always appear but the appearance may not match author expectations if
the font used does not provide the appropriate alternate glyph for all
characters contained in a subscript or superscript.

This property is not cumulative.  Applying it to elements within a
subscript or superscript won't nest the placement of a subscript or
superscript glyph. Images contained within text runs where the value
of this property is ''sub'' or ''super'' will be drawn just as they would
if the value was ''font-variant-position/normal''.

<!-- due to lack of consensus, couldn't resolve on exact positioning of text decorations:
http://www.w3.org/2013/06/06-css-minutes.html#item03 -->

Because of these limitations, 'font-variant-position' is not
recommended for use in user agent stylesheets. Authors should use it
in cases where subscripts or superscripts will only contain the narrow
range of characters supported by the fonts specified.

Note: The variant glyphs use the same baseline as the default
glyphs would use. There is no shift in the placement along the
baseline, so the use of variant glyphs doesn't affect the height of
the inline box or alter the height of the linebox.  This makes superscript
and subscript variants ideal for situations where it's important that leading
remain constant, such as in multi-column layout.

<div class="example">
	A typical user agent default style for the <code>sub</code> element:

	<pre>
	sub {
		vertical-align: sub;
		font-size: smaller;
		line-height: normal;
	}
	</pre>

	Using font-variant-position to specify typographic subscripts in a way
	that will still show subscripts in older user agents:

	<pre>
	@supports ( font-variant-position: sub ) {

		sub {
			vertical-align: baseline;
			font-size: 100%;
			line-height: inherit;
			font-variant-position: sub;
		}

	}
	</pre>

	User agents that support the 'font-variant-position' property will
	select a subscript variant glyph and render this without adjusting the
	baseline or font-size.  Older user agents will ignore the
	'font-variant-position' property definition and use the standard
	defaults for subscripts.
</div>

<h3 id="font-variant-caps-prop">Capitalization: the 'font-variant-caps' property</h3>

<pre class="propdef">
Name: font-variant-caps
Value: normal | small-caps | all-small-caps | petite-caps | all-petite-caps | unicase | titling-caps
Initial: normal
Inherited: yes
</pre>

This property allows the selection of alternate glyphs used for
small or petite capitals or for titling.  These glyphs are specifically
designed to blend well with the surrounding normal glyphs, to maintain
the weight and readability which suffers when text is simply resized to
fit this purpose.

Individual values have the following meanings:

<dl dfn-type=value dfn-for=font-variant-caps>
	<dt><dfn>normal</dfn>
	<dd>
		None of the features listed below are enabled.

	<dt><dfn>small-caps</dfn>
	<dd>
		Enables display of small capitals (OpenType feature: <code>smcp</code>).
		Small-caps glyphs typically use the form of uppercase letters but are reduced to the size of lowercase letters.

		<div class="featex"><img alt="small-caps example" src="smcp.png"></div>

	<dt><dfn>all-small-caps</dfn>
	<dd>
		Enables display of small capitals for both upper and lowercase letters (OpenType features: <code>c2sc</code>, <code>smcp</code>).

	<dt><dfn>petite-caps</dfn>
	<dd>
		Enables display of petite capitals (OpenType feature: <code>pcap</code>).

	<dt><dfn>all-petite-caps</dfn>
	<dd>
		Enables display of petite capitals for both upper and lowercase letters (OpenType features: <code>c2pc</code>, <code>pcap</code>).

	<dt><dfn>unicase</dfn>
	<dd>
		Enables display of mixture of small capitals for uppercase letters with normal lowercase letters (OpenType feature: <code>unic</code>).

	<dt><dfn>titling-caps</dfn>
	<dd>
		Enables display of titling capitals (OpenType feature: <code>titl</code>).  Uppercase
		letter glyphs are often designed for use with lowercase letters.  When used in all uppercase titling sequences
		they can appear too strong.  Titling capitals are designed specifically for this situation.
</dl>

The availability of these glyphs is based on whether a given
feature is defined or not in the feature list of the font.  User
agents can optionally decide this on a per-script basis but should
explicitly not decide this on a per-character basis.

Some fonts may only support a subset or none of the features
described for this property.  For backwards compatibility with CSS
2.1, if ''small-caps'' or ''all-small-caps'' is specified but small-caps
glyphs are not available for a given font, user agents should simulate
a small-caps font, for example by taking a normal font and replacing
the glyphs for lowercase letters with scaled versions of the glyphs
for uppercase characters (replacing the glyphs for both upper and
lowercase letters in the case of ''all-small-caps'').

<div class="figure" style="padding: 0; margin: auto;"><img class="hires" width=512 alt="synthetic vs. real small-caps" src="synthetic-vs-real-small-caps.png"><p class="caption">Synthetic vs. real small-caps</div>

To match the surrounding text, a font may provide alternate glyphs
for caseless characters when these features are enabled but when a
user agent simulates small capitals, it must not attempt to simulate
alternates for codepoints which are considered caseless.

<div class="figure" style="padding: 0; margin: auto;"><img class="hires" width=418 alt="caseless characters with small-caps, all-small-caps enabled" src="small-capitals-variations.png"><p class="caption">Caseless characters with small-caps, all-small-caps enabled</div>

If either ''petite-caps'' or ''all-petite-caps'' is specified for a
font that doesn't support these features, the property behaves as if
''small-caps'' or ''all-small-caps'', respectively, had been specified. If
''unicase'' is specified for a font that doesn't support that feature,
the property behaves as if ''small-caps'' was applied only to lowercased
uppercase letters.  If ''titling-caps'' is specified with a font that
does not support this feature, this property has no visible effect.
When simulated small capital glyphs are used, for scripts that lack uppercase and
lowercase letters, ''small-caps'', ''all-small-caps'', ''petite-caps'',
''all-petite-caps'' and ''unicase'' have no visible effect.

When casing transforms are used to simulate small capitals, the
casing transformations must match those used for the
'text-transform' property.

As a last resort, unscaled uppercase letter glyphs in a
normal font may replace glyphs in a small-caps font so that the text
appears in all uppercase letters.

<div class="figure" style="padding: 0; margin: auto;"><img class="hires" width=596 alt="using all-small-caps in acronym-laden text" src="acronym-laden-text.png"><p class="caption">Using small capitals to improve readability in acronym-laden text</div>

<div class="example">
	Quotes rendered italicised, with small-caps on the first line:

	<pre>
	blockquote            { font-style: italic; }
	blockquote:first-line { font-variant: small-caps; }

	&lt;blockquote><a href="http://lists.w3.org/Archives/Public/www-style/2009Dec/0036.html" style="text-decoration: none; border: none;">I'll be honor-bound to slap them like a haddock.</a>&lt;/blockquote>
	</pre>
</div>


<h3 id="font-variant-numeric-prop">Numerical formatting: the 'font-variant-numeric' property</h3>

<pre class="propdef">
Name: font-variant-numeric
Value: normal | [ <<numeric-figure-values>> || <<numeric-spacing-values>> || <<numeric-fraction-values>> || ordinal || slashed-zero ]
Initial: normal
Inherited: yes
</pre>

Specifies control over numerical forms. The example below shows how
some of these values can be combined to influence the rendering of
tabular data with fonts that support these features. Within normal
paragraph text, proportional numbers are used while tabular numbers
are used so that columns of numbers line up properly:

<div class="figure" style="padding: 0; margin: auto;"><img alt="combining number styles" src="numberstyles.png"><p class="caption">Using number styles</div>

Possible combinations:

<pre class="prod">
<dfn>&lt;numeric-figure-values></dfn>   = lining-nums | oldstyle-nums
<dfn>&lt;numeric-spacing-values></dfn>  = proportional-nums | tabular-nums
<dfn>&lt;numeric-fraction-values></dfn> = diagonal-fractions | stacked-fractions
</pre>

Individual values have the following meanings:

<dl dfn-type=value>
	<dt><dfn for="font-variant-numeric">normal</dfn>
	<dd>None of the features listed below are enabled.

	<dt><dfn for="font-variant-numeric <numeric-figure-values>">lining-nums</dfn>
	<dd>Enables display of lining numerals (OpenType feature: <code>lnum</code>).

	<dt><dfn for="font-variant-numeric <numeric-figure-values">oldstyle-nums</dfn>
	<dd>Enables display of old-style numerals (OpenType feature: <code>onum</code>).

	<dt><dfn for="font-variant-numeric <numeric-spacing-values>">proportional-nums</dfn>
	<dd>Enables display of proportional numerals (OpenType feature: <code>pnum</code>).

	<dt><dfn for="font-variant-numeric <numeric-spacing-values>">tabular-nums</dfn>
	<dd>Enables display of tabular numerals (OpenType feature: <code>tnum</code>).

	<dt><dfn for="font-variant-numeric <numeric-fraction-values>">diagonal-fractions</dfn>
	<dd>Enables display of lining diagonal fractions (OpenType feature: <code>frac</code>).
		<div class="featex"><img alt="diagonal fraction example" src="frac.png"></div>

	<dt><dfn for="font-variant-numeric <numeric-fraction-values>">stacked-fractions</dfn>
	<dd>Enables display of lining stacked fractions (OpenType feature: <code>afrc</code>).
		<div class="featex"><img alt="stacked fraction example" src="afrc.png"></div>

	<dt><dfn for="font-variant-numeric">ordinal</dfn>
	<dd>Enables display of letter forms used with ordinal numbers (OpenType feature: <code>ordn</code>).
		<div class="featex"><img alt="ordinals example" src="ordinals.png"></div>

	<dt><dfn for="font-variant-numeric">slashed-zero</dfn>
	<dd>Enables display of slashed zeros (OpenType feature: <code>zero</code>).
		<div class="featex"><img alt="slashed zero example" src="zero.png"></div>

</dl>

<div id="ordinal-example" class="example">
	In the case of ''ordinal'', although ordinal forms
	are often the same as superscript forms, they are marked up
	differently.
	For superscripts, the variant property is only applied to the sub-element containing the superscript:

	<pre>
	sup { font-variant-position: super; }
	x&lt;sup&gt;2&lt;/sup&gt;
	</pre>

	For ordinals, the variant property is applied to the entire ordinal number rather than
	just to the suffix (or to the containing paragraph):

	<pre>
	.ordinal { font-variant-numeric: ordinal; }
	&lt;span class="ordinal"&gt;17th&lt;/span&gt;
	</pre>

	In this case only the "th" will appear in ordinal form, the
	digits will remain unchanged. Depending upon the typographic
	traditions used in a given language, ordinal forms may differ from
	superscript forms. In Italian, for example, ordinal forms sometimes
	include an underline in the ordinal design.
</div>

<div class="example" id="steak-marinade">
	A simple flank steak marinade recipe, rendered with automatic fractions and old-style numerals:

	<pre>
	.amount { font-variant-numeric: oldstyle-nums diagonal-fractions; }

	&lt;h4>Steak marinade:&lt;/h4>
	&lt;ul>
		&lt;li>&lt;span class="amount">2&lt;/span> tbsp olive oil&lt;/li>
		&lt;li>&lt;span class="amount">1&lt;/span> tbsp lemon juice&lt;/li>
		&lt;li>&lt;span class="amount">1&lt;/span> tbsp soy sauce&lt;/li>
		&lt;li>&lt;span class="amount">1 1/2&lt;/span> tbsp dry minced onion&lt;/li>
		&lt;li>&lt;span class="amount">2 1/2&lt;/span> tsp italian seasoning&lt;/li>
		&lt;li>Salt &amp;amp; pepper&lt;/li>
	&lt;/ul>

	&lt;p>Mix the meat with the marinade and let it sit covered in the refrigerator
	for a few hours or overnight.&lt;/p>
	</pre>

	Note that the fraction feature is only applied to values not the entire paragraph.
	Fonts often implement this feature using contextual rules based on the use of the slash ('/')
	character.  As such, it's not suitable for use as a paragraph-level style.
</div>


<h3 id="font-variant-alternates-prop">Alternates and swashes: the 'font-variant-alternates' property</h3>

<pre class="propdef">
Name: font-variant-alternates
Value: normal |
Value: [
Value:   stylistic(<<feature-value-name>>) || historical-forms || styleset(<<feature-value-name>>#) ||
Value:   character-variant(<<feature-value-name>>#) || swash(<<feature-value-name>>) || ornaments(<<feature-value-name>>) ||
Value:   annotation(<<feature-value-name>>)
Value: ]
Initial: normal
Inherited: yes
</pre>

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

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

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

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

When a particular <<feature-value-name>> 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 <<feature-value-name>>
identifiers must be ignored when choosing glyphs.

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

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:

<dl dfn-type=value dfn-for=font-variant-alternates>
	<dt><dfn>normal</dfn>
	<dd>None of the features listed below are enabled.

	<dt><dfn>historical-forms</dfn>
	<dd>Enables display of historical forms (OpenType feature: <code>hist</code>).
		<div class="featex"><img alt="historical form example" src="hist.png"></div>

	<dt><dfn lt="stylistic()">stylistic(<<feature-value-name>>)</dfn>
	<dd>Enables display of stylistic alternates (<a>font specific</a>, OpenType feature: <code>salt <<feature-index>></code>).
		<div class="featex"><img alt="stylistic alternate example" src="salt.png"></div>

	<dt><dfn lt="styleset()">styleset(<<feature-value-name>>#)</dfn>
	<dd>Enables display with stylistic sets (<a>font specific</a>, OpenType feature: <code>ss<<feature-index>></code>
		OpenType currently defines <code>ss01</code> through <code>ss20</code>).
		<div class="featex"><img alt="styleset example" src="ssnn.png"></div>

	<dt><dfn lt="character-variant()">character-variant(<<feature-value-name>>#)</dfn>
	<dd>Enables display of specific character variants (<a>font specific</a>, OpenType feature: <code>cv<<feature-index>></code>
		OpenType currently defines <code>cv01</code> through <code>cv99</code>).

	<dt><dfn lt="swash()">swash(<<feature-value-name>>)</dfn>
	<dd>Enables display of swash glyphs (<a>font specific</a>, OpenType feature: <code>swsh <<feature-index>>, cswh <<feature-index>></code>).
		<div class="featex"><img alt="swash example" src="swsh.png"></div>

	<dt><dfn lt="ornaments()">ornaments(<<feature-value-name>>)</dfn>
	<dd>Enables replacement of default glyphs with ornaments, if provided in the font (<a>font specific</a>, OpenType feature: <code>ornm <<feature-index>></code>).
		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''.
		<div class="featex"><img alt="ornaments example" src="ornm.png"></div>

	<dt><dfn lt="annotation()">annotation(<<feature-value-name>>)</dfn>
	<dd>Enables display of alternate annotation forms (<a>font specific</a>, OpenType feature: <code>nalt <<feature-index>></code>).
		<div class="featex"><img alt="alternate annotation form example" src="nalt.png"></div>
</dl>

<h3 id="font-feature-values">Defining font specific alternates: the <dfn>@font-feature-values</dfn> rule</h3>

Several of the possible values of 'font-variant-alternates' listed
above are labeled as <a>font specific</a>.  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.

Note: See [[#om-fontfeaturevalues]] for a
description of the interfaces used to modify these rules via the CSS
Object Model.

<div class="example">
	In the case of the swash Q in the example shown above, the swash could
	be specified using these style rules:

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

	&lt;h2>Quick&lt;/h2>
	</pre>

	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 ech alternate is defined within a given font's data.
</div>

<h4 id='basic-syntax'>Basic syntax</h4>

An ''@font-feature-values'' rule is composed of a list of
font families followed by a block containing individual
<a lt="feature_value_block">feature value blocks</a> 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 &#x27e8;family, feature, ident&#x27e9; &rarr; &#x27e8;values&#x27e9;
where &#x27e8;values&#x27e9; are the numeric indices used for specific
features defined for a given font.

In terms of the grammar, this specification defines the following productions:

<pre><dfn>font_feature_values_rule</dfn>
	: <a>FONT_FEATURE_VALUES_SYM</a> <a href="http://www.w3.org/TR/CSS21/grammar.html#scanner"><a>S</a></a>* <a>font_family_name_list</a> <a href="http://www.w3.org/TR/CSS21/grammar.html#scanner"><a>S</a></a>*
		'{' <a href="http://www.w3.org/TR/CSS21/grammar.html#scanner"><a>S</a></a>* <a>feature_value_block</a>? [ <a href="http://www.w3.org/TR/CSS21/grammar.html#scanner"><a>S</a></a>* <a>feature_value_block</a>? ]* '}' <a href="http://www.w3.org/TR/CSS21/grammar.html#scanner"><a>S</a></a>*
	;

<dfn>font_family_name_list</dfn>
	: <a>font_family_name</a> [ <a href="http://www.w3.org/TR/CSS21/grammar.html#scanner"><a>S</a></a>* ',' <a href="http://www.w3.org/TR/CSS21/grammar.html#scanner"><a>S</a></a>* <a>font_family_name</a> ]*
	;

<dfn>font_family_name</dfn>
	: <a href="http://www.w3.org/TR/CSS21/syndata.html#tokenization"><a>STRING</a></a> | [ <a href="http://www.w3.org/TR/CSS21/syndata.html#tokenization"><a>IDENT</a></a> [ <a href="http://www.w3.org/TR/CSS21/grammar.html#scanner"><a>S</a></a>* <a href="http://www.w3.org/TR/CSS21/syndata.html#tokenization"><a>IDENT</a></a> ]* ]
	;

<dfn>feature_value_block</dfn>
	: <a>feature_type</a> <a href="http://www.w3.org/TR/CSS21/grammar.html#scanner"><a>S</a></a>*
		'{' <a href="http://www.w3.org/TR/CSS21/grammar.html#scanner"><a>S</a></a>* <a>feature_value_definition</a>? [ <a href="http://www.w3.org/TR/CSS21/grammar.html#scanner"><a>S</a></a>* ';' <a href="http://www.w3.org/TR/CSS21/grammar.html#scanner"><a>S</a></a>* <a>feature_value_definition</a>? ]* '}' <a href="http://www.w3.org/TR/CSS21/grammar.html#scanner"><a>S</a></a>*
	;

<dfn>feature_type</dfn>:
	<a href="http://www.w3.org/TR/CSS21/syndata.html#tokenization"><a>ATKEYWORD</a></a>
	;

<dfn>feature_value_definition</dfn>
	: <a href="http://www.w3.org/TR/CSS21/syndata.html#tokenization"><a>IDENT</a></a> <a href="http://www.w3.org/TR/CSS21/grammar.html#scanner"><a>S</a></a>* ':' <a href="http://www.w3.org/TR/CSS21/grammar.html#scanner"><a>S</a></a>* <a href="http://www.w3.org/TR/CSS21/syndata.html#tokenization"><a>NUMBER</a></a> [ <a href="http://www.w3.org/TR/CSS21/grammar.html#scanner"><a>S</a></a>* <a href="http://www.w3.org/TR/CSS21/syndata.html#tokenization"><a>NUMBER</a></a> ]*
	;
</pre>

The following new token is introduced:

<pre>@{F}{O}{N}{T}{-}{F}{E}{A}{T}{U}{R}{E}{-}{V}{A}{L}{U}{E}{S}   {return <dfn>FONT_FEATURE_VALUES_SYM</dfn>;}
</pre>

<a lt="feature_value_block">Feature value blocks</a> are handled as
<a href="http://www.w3.org/TR/CSS2/syndata.html#at-rules">at-rules</a>,
they consist of everything up to the next block or
semi-colon, whichever comes first.

The <a lt="font_family_name_list">font family list</a> is a comma-delimited list of
<a lt="font_family_name">font family names</a> that match the definition of <var>&lt;family-name&gt;</var>
for the 'font-family' 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 <a lt="feature_value_block">feature value blocks</a>,
the <a lt="feature_type">feature type</a> is "@"" followed by the
name of one of the <a>font specific</a> property values
of 'font-variant-alternates' (e.g. <code>swash</code>). The
identifiers used within feature value definitions define <dfn>&lt;feature-value-name></dfn>s
and follow the rules of
CSS user identifiers and are case-sensitive. They are unique only for
a given set of font families and <a lt="feature_type">feature type</a>.
The same identifier used with a different <a lt="feature_type">feature type</a>
is treated as a separate and distinct value.  If the same identifier is defined
mulitple times for a given <a lt="feature_type">feature type</a> and font family,
the last defined value is used. Values associated
with a given identifier are <dfn>&lt;feature-index></dfn>es and are limited to integer values 0 or greater.

When syntax errors occur within a <a lt="feature_value_definition">feature value
definition</a>, such as invalid identifiers or values, the entire <a lt="feature_value_definition">feature value
definition</a> must be omitted, just as syntax errors in
style declarations are handled.  When the <a lt="feature_type">feature type</a>
is invalid, the entire associated
<a lt="feature_value_block">feature value block</a> must be ignored.

<div class="example">
	Rules that are equivalent given syntax error handling:

	<pre>
	@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 ; */
		<a style="text-decoration: none; border: none;" href="http://www.angryalien.com/0504/shiningbunnies.html">redrum</a>  /* random editing mistake */
	}
	</pre>

	The example above is equivalent to:

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

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.

<div class="example">
	Using both site-wide and per-page feature values:

	<pre>
	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);
		}
	</pre>
</div>

<div class="example">
	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:

	<pre>
	@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);
	}
	</pre>
</div>

<h4 id='multi-valued-features'>Multi-valued feature value definitions</h4>

Most <a>font specific</a> 'font-variant-alternates' property
values 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
<code>ss01</code> through <code>ss99</code>.
However, the OpenType standard only officially defines
<code>ss01</code> through <code>ss20</code>.
For OpenType fonts, values greater than 99 or equal to 0 do not
generate a syntax error when parsed but enable no OpenType features.


<pre>
@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;        /* &gt;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);
}
</pre>

For character-variant, a single value between 1 and 99 indicates
the enabling of OpenType feature <code>cv01</code> through
<code>cv99</code>. 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
<a lt="feature_value_definition">feature value definition</a> is
ignored.

<pre>
@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; }     /* &gt;99, ignored */
	@character-variant { dumb: 323 3; }    /* &gt;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);
}
</pre>


<div class="example">
	<div class="figure"><img alt="Matching text on Byzantine seals using character variants" src="byzantineseal.png" /><p class="caption">Byzantine seal text displayed with character variants</div>

	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.

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

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

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

<h3 id="font-variant-east-asian-prop">East Asian text rendering: the 'font-variant-east-asian' property</h3>

<pre class="propdef">
Name: font-variant-east-asian
Value: normal | [ <<east-asian-variant-values>> || <<east-asian-width-values>> || ruby ]
Initial: normal
Inherited: yes
</pre>

Allows control of glyph substitution and sizing in East Asian text.

<pre class="prod">
<dfn>&lt;east-asian-variant-values></dfn> = jis78 | jis83 | jis90 | jis04 | simplified | traditional
<dfn>&lt;east-asian-width-values></dfn>   = full-width | proportional-width
</pre>

Individual values have the following meanings:

<dl dfn-type=value>
	<dt><dfn for="font-variant-east-asian">normal</dfn>
	<dd>None of the features listed below are enabled.

	<dt><dfn for="font-variant-east-asian <east-asian-variant-values>">jis78</dfn>
	<dd>Enables rendering of JIS78 forms (OpenType feature: <code>jp78</code>).
		<div class="featex"><img alt="JIS78 form example" src="jp78.png"></div>

	<dt><dfn for="font-variant-east-asian <east-asian-variant-values>">jis83</dfn>
	<dd>Enables rendering of JIS83 forms (OpenType feature: <code>jp83</code>).

	<dt><dfn for="font-variant-east-asian <east-asian-variant-values>">jis90</dfn>
	<dd>Enables rendering of JIS90 forms (OpenType feature: <code>jp90</code>).

	<dt><dfn for="font-variant-east-asian <east-asian-variant-values>">jis04</dfn>
	<dd>Enables rendering of JIS2004 forms (OpenType feature: <code>jp04</code>).

		The various JIS variants reflect the glyph forms defined in different
		Japanese national standards. Fonts generally include glyphs defined by the
		most recent national standard but it's sometimes necessary to use older
		variants, to match signage for example.

	<dt><dfn for="font-variant-east-asian <east-asian-variant-values>">simplified</dfn>
	<dd>Enables rendering of simplified forms (OpenType feature: <code>smpl</code>).

	<dt><dfn for="font-variant-east-asian <east-asian-variant-values>">traditional</dfn>
	<dd>Enables rendering of traditional forms (OpenType feature: <code>trad</code>).

		The ''simplified'' and ''traditional'' values allow control over the
		glyph forms for characters which have been simplified over time but
		for which the older, traditional form is still used in some
		contexts.  The exact set of characters and glyph forms will vary
		to some degree by context for which a given font was designed.
		<div class="featex"><img alt="tradtional form example" src="trad.png"></div>

	<dt><dfn for="font-variant-east-asian <east-asian-width-values>">full-width</dfn>
	<dd>Enables rendering of full-width variants (OpenType feature: <code>fwid</code>).

	<dt><dfn for="font-variant-east-asian <east-asian-width-values>">proportional-width</dfn>
	<dd>Enables rendering of proportionally-spaced variants (OpenType feature: <code>pwid</code>).
		<div class="featex"><img alt="proportionally spaced Japanese example" src="pwid.png"></div>

	<dt><dfn for="font-variant-east-asian">ruby</dfn>
	<dd>Enables display of ruby variant glyphs (OpenType feature: <code>ruby</code>).
		Since ruby text is generally smaller than the associated body
		text, font designers can design special glyphs for use with ruby
		that are more readable than scaled down versions of the default
		glyphs.  Only glyph selection is affected, there is no
		associated font scaling or other change that affects line layout.
		The red ruby text below is shown with default glyphs (top) and
		with ruby variant glyphs (bottom).  Note the slight difference
		in stroke thickness.
		<div class="featex"><img alt="ruby variant example" src="rubyshinkansen.png"></div>
</dl>

<h3 id="font-variant-prop">Overall shorthand for font rendering: the 'font-variant' property</h3>

<pre class="propdef shorthand">
Name: font-variant
Value: normal | none |
Value: [
Value:   <<common-lig-values>> || <<discretionary-lig-values>> || <<historical-lig-values>> || <<contextual-alt-values>> ||
Value:   stylistic(<<feature-value-name>>) || historical-forms || styleset(<<feature-value-name>>#) ||
Value:   character-variant(<<feature-value-name>>#) || swash(<<feature-value-name>>) || ornaments(<<feature-value-name>>) ||
Value:   annotation(<<feature-value-name>>) || [ small-caps | all-small-caps | petite-caps | all-petite-caps | unicase | titling-caps ] ||
Value:   <<numeric-figure-values>> || <<numeric-spacing-values>> || <<numeric-fraction-values>> || ordinal || slashed-zero ||
Value:   <<east-asian-variant-values>> || <<east-asian-width-values>> || ruby
Value: ]
</pre>

The 'font-variant' property is a shorthand for all 'font-variant-*' subproperties.
The value <dfn value for=font-variant>normal</dfn> resets all subproperties of 'font-variant' to their inital
value. The <dfn value for=font-variant>none</dfn> value sets 'font-variant-ligatures' to ''font-variant-ligatures/none'' and resets all other
font feature properties to their initial value.  Like other shorthands,
using 'font-variant' resets unspecified 'font-variant' subproperties to their initial
values.  It does not reset the values of either 'font-language-override' or
'font-feature-settings'.


<h3 id="font-feature-settings-prop">Low-level font feature settings control: the 'font-feature-settings' property</h3>

<pre class="propdef">
Name: font-feature-settings
Value: normal | <<feature-tag-value>>#
Initial: normal
Inherited: yes
</pre>

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

Authors should generally use 'font-variant'
and its related subproperties whenever possible and only use this
property for special cases where its use is the only way of accessing
a particular infrequently used font feature.

<pre>/* enable small caps and use second swash alternate */
font-feature-settings: "smcp", "swsh" 2;</pre>

A value of <dfn value for=font-feature-settings>normal</dfn> means that no
change in glyph selection or positioning occurs due to this property.

Feature tag values have the following syntax:

<pre class="prod"><dfn>&lt;feature-tag-value></dfn> = <<string>> [ <<integer>> | on | off ]?</pre>

The <<string>> is a case-sensitive OpenType feature tag. As
specified in the OpenType specification, feature tags contain four
ASCII characters. Tag strings longer or shorter than four characters,
or containing characters outside the U+20&ndash;7E codepoint range are
invalid.  Feature tags need only
match a feature tag defined in the font, so they are not limited to
explicitly registered OpenType features. Fonts defining custom feature
tags should follow the
<a href="http://www.microsoft.com/typography/otspec/featuretags.htm">tag name rules</a>
defined in the OpenType specification [[!OPENTYPE-FEATURES]].

Feature tags not present in the font are ignored; a user agent must
not attempt to synthesize fallback behavior based on these feature
tags.  The one exception is that user agents may synthetically support
the <code>kern</code> feature with fonts that contain
kerning data in the form of a "kern" table but lack
<code>kern</code> feature support in the "GPOS" table.

Note: In general, authors should use the 'font-kerning' property to
explicitly enable or disable kerning since this property always affects
fonts with either type of kerning data.

If present, a value indicates an index used for glyph selection.
An <<integer>> value must be 0 or greater. A value of 0
indicates that the feature is disabled.  For boolean features, a
value of 1 enables the feature.  For non-boolean features, a value
of 1 or greater enables the feature and indicates the feature
selection index. A value of ''on'' is synonymous with 1 and ''off'' is
synonymous with 0. If the value is omitted, a value of 1 is assumed.

<div class="example">
	Examples:

	<pre>
	font-feature-settings: "dlig" 1;       /* dlig=1 enable discretionary ligatures */
	font-feature-settings: "smcp" on;      /* smcp=1 enable small caps */
	font-feature-settings: "c2sc";         /* c2sc=1 enable caps to small caps */
	font-feature-settings: "liga" off;     /* liga=0 no common ligatures */
	font-feature-settings: "tnum", "hist"; /* tnum=1, hist=1 enable tabular numbers and historical forms */
	font-feature-settings: "tnum" "hist";  /* invalid, need a comma-delimited list */
	font-feature-settings: "silly" off;    /* invalid, tag too long */
	font-feature-settings: "PKRN";         /* PKRN=1 enable custom feature */
	font-feature-settings: dlig;           /* invalid, tag must be a string */
	</pre>
</div>

When values greater than the range supported by the font are
specified, the behavior is explicitly undefined.  For boolean
features, in general these will enable the feature.  For non-boolean
features, out of range values will in general be equivalent to a 0
value.  However, in both cases the exact behavior will depend upon the
way the font is designed (specifically, which type of lookup is used
to define the feature).

Although specifically defined for OpenType feature tags, feature
tags for other modern font formats that support font features may be
added in the future.  Where possible, features defined for other font
formats should attempt to follow the pattern of registered OpenType
tags.

<div class="example">
	The Japanese text below will be rendered with half-width kana characters:

	<pre lang="ja">
	body { font-feature-settings: "hwid"; /* Half-width OpenType feature */ }

	&lt;p>毎日<a href="http://images.google.com/images?q=%E3%82%AB%E3%83%AC%E3%83%BC" style="text-decoration: none;">カレー</a>食べてるのに、飽きない&lt;/p>
	</pre>
</div>

<h3 id="font-language-override-prop">Font language override: the 'font-language-override' property</h3>

<pre class="propdef">
Name: font-language-override
Value: normal | <<string>>
Initial: normal
Inherited: yes
</pre>

Normally, authors can control the use of language-specific glyph substitutions and positioning
by setting the content language of an element, as described in [[#language-specific-support]]:

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

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

Values have the following meanings:

<dl dfn-type=value dfn-for=font-language-override>
	<dt><dfn>normal</dfn>
	<dd>specifies that when rendering with OpenType fonts,
		the content language of the element is used to infer the OpenType language system
	<dt><dfn><<string>></dfn>
	<dd>single three-letter case-sensitive OpenType <a href="http://www.microsoft.com/typography/otspec/languagetags.htm">language system tag</a>,
		specifies the OpenType language system to be used instead of the language system implied by the language of the element
</dl>

<!-- For this level, string represents a single language code, there's no concept of "fallback"
http://www.w3.org/2013/06/07-css-minutes.html#item04 -->

Use of invalid OpenType language system tags must not generate a
parse error but must be ignored when doing glyph selection and
placement.

<div class="example">
	The <a href="http://www.un.org/en/documents/udhr/index.shtml">Universal Declaration of Human Rights</a> has
	been translated into a wide variety of languages.  In Turkish, Article 9 of this document might be marked up as below:

	<pre lang="tr">
	&lt;body lang="tr">

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

	Here the user agent uses the value of the <code>lang</code> attribute when rendering text and
	appropriately renders this text without "fi" ligatures.  There is no need
	to use the 'font-language-override' 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:

	<pre lang="mk">
	&lt;body lang="mk">     &lt;!-- Macedonian lang code --&gt;

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

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

	The Macedonian text here will be rendered using Serbian typographic conventions, with the
	assumption that the font specified supports Serbian.
</div>

<h2 id="font-feature-resolution">
Font Feature Resolution
<span id="rendering-considerations"></span>
</h3>

As described in the previous section, font features can be enabled
in a variety of ways, either via the use of 'font-variant' or
'font-feature-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.

<h3 id="default-features">Default features</h3>

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: <code>rlig</code>, <code>liga</code>, <code>clig</code>, <code>calt</code>),
along with localized forms (OpenType feature: <code>locl</code>),
and features required for proper display of composed characters and marks
(OpenType features: <code>ccmp</code>, <code>mark</code>, <code>mkmk</code>).  These features
must always be enabled, even when the value of the
'font-variant' and
'font-feature-settings' properties is
''font-variant/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
<a href="http://www.microsoft.com/typography/otfntdev/arabicot/features.aspx">Arabic</a>,
<a href="http://www.microsoft.com/typography/otfntdev/mongolot/features.htm">Mongolian</a> or
<a href="http://www.microsoft.com/typography/otfntdev/devanot/features.aspx">Devanagari</a>
additional features are required.  For upright text within vertical text runs, vertical
alternates (OpenType feature: <code>vert</code>) must be enabled.

<h3 id="feature-precedence">Feature precedence</h3>

General and <a>font specific</a> 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.

<ol>
	<li>Font features enabled by default, including features required for a given script.

	<li>If the font is defined via an ''@font-face'' rule, the font features
	implied by the font-variant descriptor in the ''@font-face'' rule.

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

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

	<!-- other CSS props override 'font-variant' but not 'font-feature-settings' -->
	<!-- http://lists.w3.org/Archives/Public/www-style/2013Aug/0110.html -->

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

	<li>Font features implied by the value of 'font-feature-settings' property.
</ol>

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.


<h3 id="feature-precedence-examples">Feature precedence examples</h3>

<div class="example">
	With the styles below, numbers are rendered proportionally when used within
	a paragraph but are shown in tabular form within tables of prices:

	<pre>
	body {
		font-variant-numeric: proportional-nums;
	}

	table.prices td {
		font-variant-numeric: tabular-nums;
	}
	</pre>
</div>

<div class="example">
	When the ''@font-face/font-variant'' descriptor
	is used within an ''@font-face'' rule, it only
	applies to the font defined by that rule.

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

	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.
</div>

<div class="example">
	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:

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

	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.
</div>

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

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

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

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

	In this case, discretionary ligatures <em>will</em> 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 <code>dlig</code> feature, because the 'font-feature-settings'
	is resolved after that, the ''dlig'' value reenables discretionary ligatures.
</div>

<h2 id="object-model">Object Model</h2>

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

<h3 id="om-fontface">The {{CSSFontFaceRule}} interface</h3>

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

<pre class="idl">
interface CSSFontFaceRule : CSSRule {
	attribute DOMString family;
	attribute DOMString src;
	attribute DOMString style;
	attribute DOMString weight;
	attribute DOMString stretch;
	attribute DOMString unicodeRange;
	attribute DOMString variant;
	attribute DOMString featureSettings;
};
</pre>

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

<h3 id="om-fontfeaturevalues">The {{CSSFontFeatureValuesRule}} interface</h3>

The {{CSSRule}} interface is extended as follows:

<pre class='idl'>
partial interface CSSRule {
	const unsigned short FONT_FEATURE_VALUES_RULE = 14;
};
</pre>

The <dfn interface >CSSFontFeatureValuesRule</dfn> interface represents a ''@font-feature-values'' rule.

<pre class='idl'>
interface CSSFontFeatureValuesRule : CSSRule {
	attribute DOMString fontFamily;
	readonly attribute CSSFontFeatureValuesMap annotation;
	readonly attribute CSSFontFeatureValuesMap ornaments;
	readonly attribute CSSFontFeatureValuesMap stylistic;
	readonly attribute CSSFontFeatureValuesMap swash;
	readonly attribute CSSFontFeatureValuesMap characterVariant;
	readonly attribute CSSFontFeatureValuesMap styleset;
};

[MapClass(DOMString, sequence&lt;unsigned long&gt;)]
interface CSSFontFeatureValuesMap {
	void set(DOMString featureValueName,
	         (unsigned long or sequence&lt;unsigned long&gt;) values);
};
</pre>

<dl dfn-type=attribute dfn-for=CSSFontFeatureValuesRule>
	<dt><dfn>fontFamily</dfn> <span attribute-info for=fontFamily></span>
	<dd>The list of one or more font families for which a given set of feature values is defined.

	<dt><dfn>annotation</dfn> <span attribute-info for=annotation></span>
	<dt><dfn>ornaments</dfn> <span attribute-info for=ornaments></span>
	<dt><dfn>stylistic</dfn> <span attribute-info for=stylistic></span>
	<dt><dfn>swash</dfn> <span attribute-info for=swash></span>
	<dt><dfn>characterVariant</dfn> <span attribute-info for=characterVariant></span>
	<dt><dfn>styleset</dfn> <span attribute-info for=styleset></span>
	<dd>Maps of feature values associated with feature value names for a given 'font-variant-alternates' value type
</dl>

Each value map attribute of {{CSSFontFeatureValuesRule}} reflects the values
defined via a corresponding <a lt="feature_value_block">feature value block</a>.
Thus, the {{annotation}} attribute
contains the values contained within a ''@annotation''
<a lt="feature_value_block">feature value block</a>, the
{{ornaments}} attribute contains the
values contained with a ''@ornaments''
<a lt="feature_value_block">feature value block</a> and so forth.

The {{CSSFontFeatureValuesMap}} interface uses the
<a href="http://dev.w3.org/2006/webapi/WebIDL/#es-map-members">default map class methods</a>
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
<a lt="feature_value_block">feature value block</a>
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 <a href="#multi-valued-features">multi-valued feature value definitions</a>
for details on the maximum number of values allowed for a given type
of <a lt="feature_value_block">feature value block</a>.  The {{get()}}
method always returns a sequence of values, even if the sequence only contains
a single value.

<h2 id="platform-props-to-css" class="no-num">Appendix A: Mapping platform font properties to CSS properties</h2>

<em>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.</em>

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 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 <a>character map</a> ("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]].

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 <a>character map</a>
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.  Mulitple 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.

<h2 class="no-num" id="ch-ch-ch-changes">Changes</h2>
	<h3 class="no-num" id="recent-changes">
	Changes from the <a href="http://www.w3.org/TR/2013/WD-css-fonts-3-20130711/">July 2013 CSS3 Fonts Last Call Working Draft</a></h3>

	<ul>
		<li>reorder feature precedence such that features implied by other CSS properties override 'font-variant' settings
		<li>switched examples to use .woff files
		<li>revised wording of font fetching algorithm
		<li>drop <css>auto</css> value for 'font-size-adjust'
		<li>clarify effect of 'font-size-adjust' on 'line-height'
		<li>allow user agents to synthesize OpenType <code>kern</code> feature
		<li>add example of ordinals and associated markup
		<li>minor editorial cleanups
	</ul>

<h2 class=no-num id=acknowledgments>Acknowledgments</h2>

I'd like to thank Tal Leming, Jonathan Kew and Christopher Slye for
all their help and feedback.  John Hudson was kind enough to take the
time to explain the subtleties of OpenType language tags and provided
the example of character variant usage for displaying text on
Byzantine seals. Ken Lunde and Eric Muller provided valuable feedback
on CJK OpenType features and Unicode variation selectors. The idea for
supporting font features by using 'font-variant' subproperties
originated with Håkon Wium Lie, Adam Twardoch and Tal Leming.  Elika
Etemad supplied some of the initial design ideas for the
''@font-feature-values'' rule.  Thanks also to House Industries for
allowing the use of Ed Interlock in the discretionary ligatures
example.

A special thanks to Robert Bringhurst for the sublime mind expansion
that is <em>The Elements of Typographic Style</em>.