This is (soon to be) a W3C Working Draft for review by W3C members and other interested parties. It is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress".
Within W3C, a working group on fonts has been established to discuss how fonts can be integrated onto the Web. This document is one of three "working drafts" that deliverables of the group.
This document discusses how to reference fonts on the Web. More specifically, it outlines ways of referencing fonts -- both locally installed fonts as well fonts on the web -- from HTML documents. Also, strategies for finding the right font in over- and under-constrained problems are described.
The Web needs a way to reference fonts. More specifically, we need a way to attach information about requested fonts to HTML documents (also, other media types need font solutions in the future).
It must be possible to:
HTML is a simple document format much in use on the Web. HTML comes from the world of structured documents formally defined in SGML. In the last few years, HTML has been under pressure to add tags and attributes to represent the visual presentation of a document. Among the elements that have been introduced by browser vendors are:
Some of the extensions have been widely deployed on the Web, and e.g. CENTER and FONT (with the SIZE and COLOR attributes, but not FACE) are likely to appear in the forth-coming HTML 3.2.
Style sheets provide an alternative way of improving the presentation of Web documents. CSS1 has been developed by W3C in cooperation with its members and is starting to be supported in commercial browsers. Compared to HTML extensions, style sheets:
For these reasons, CSS style sheets will be the glue that connects HTML with fonts. However, browsers do not need to support the full CSS1 specification to implement WebFonts; a required subset is defined in this specification.
CSS1[ref] is a specification of a simple style sheet language. Although general in principle, CSS1 has been developed in the context of HTML and offers features much requested on the Web: control over white space, color, backgrounds and fonts.
CSS1 has two main goals:
The list of properties and values is expected to grow as the demands on HTML presentations increase: fonts, high-quality printing, aural renderings. The CSS mechanism has been designed to scale up to these demands.
CSS1 defines several properties to describe the requested font:
H1 {
font-weight: bold;
font-size: 12pt;
line-height: 14pt;
font-family: Univers, sans-serif;
font-style: normal
}
The current CSS approach relies on an underlying font matching mechanism that the UA (or underlying system) must provide. In the above example, if "Univers" is not available, the the UA must be able to resolve the generic font family "sans-serif" into a locally available font family.
While the CSS1 properties give designers sufficient font control for a wide range of documents, they do not provide ability to refer to one specific font, possibly referenced through a URL. This document describes how CSS1 is extended to add this functionality.
To support the concept of WebFonts, we propose to add two constructs to CSS: a new property ('font-face') and a new "@-rule" to contain a font description.
A "font description" is a collection of all information know about a certain type face. Information may include URLs from where the font face can be fetched, the weight of the font face, and the widths of the glyphs.
The proposed 'font-face' property is used to uniquely identify a certain font description. Each element in the HTML document may have a different value for 'font-face'.
Let's look at a sample HTML document:
<HTML>
<STYLE TYPE=text/css>
@font-face real_cool {
font-family: Stone;
font-weight: bold;
src: url(http://font/stone/bold);
widths: 765 098 654 987 [etc.]
}
</STYLE>
<BODY>
<P STYLE="font-face: real_cool">...
<P STYLE="font-family: Stone; font-weight: bold">...
</BODY>
</HTML>
In the example above, there is one font description inside the STYLE element. A font description consists of "@font-face", an (optional?) font description name, and a block ({ .. }) with font description properties.
In the above example there are two P elements inside the BODY element:
Thus, in the example above, the two P elements will both use the 'real_cool' font face.
The font description is a grouping of all information that is know about a certain font face, e.g. the name of the font-family, the Panose number, the widths of all glyphs, and a list of URLs from where the font can be downloaded.
The names and values of the font declaration properties have not yet been worked out
unicode-range units-per-em src dfnsrc? signature panose stemv stemh italic-angle cap-height xheight ascent descent subset-chars widths bbox default-width
Also, the CSS1 font properties need to be present in order to do matching from 'font-family', 'font-weight' and 'font-style'.
Document created on-the-fly will sometimes need to add font descriptions in the middle of a document. To allow for this, is is suggested that the 'STYLE' element is allowed also inside the 'BODY' element:
<HTML>
<HEAD>
<TITLE> </TITLE>
<STYLE>
@font-face gill_sans {
..
}
H1 { font-face: gill_sans }
</STYLE&g;
</HEAD>
<BODY>
<H1>Lettering</H1>
<STYLE>
@font-face futura {
..
}
H2 { font-face: futura }
</STYLE>
<H2>Typography</H2>
</BODY>
</HTML>
Style sheets inside the 'BODY' element should be cascaded in the order they appear. It is the author's responsibility not to change any style rules for elements that have already occurred earlier in the document since this will make progressive rendering impossible.
Deciding where to look for fonts and what font to display on the screen (or on paper) at what time is potentially a complex problem. Variables in the equation include network performance, machine CPU, reader's wait costs, reader's display device, visual quality demands, font costs and legal restrictions. The optimal solution to this equation will vary between readers, display devices and documents.
Instead of trying to solve the above equation or defining means for authors and readers to specify solutions, this specification suggests a fixed list that is to be traversed until the font face can be rendered on the canvas.
If the UA is left without a usable font face after traversing the above list, the font description can be discarded. If the UA supports CSS1, a font should now be found according to the CSS1 specification. Other UAs should must have their own strategies for finding a fall back font.
When a UA formats an HTML document, it needs to find a font face for all textual elements. Traditional browsers have a matching table that is hardcoded or resides in a static resource file. Browsers that support style sheets allow authors and readers to dynamically change the the matching table (among other things).
As briefly described in the above example, the 'font-face' property is a way to refer to a font description from an HTML element. Following the CSS1 convention, 'font-face' is defined as:
The value of this property, if defined, refers to a "font description" that contains information about the preferred font face.
minimal example appears here
Subject to UA preferences and availability, the font face described in the font description will be used for the given element.
This property should be used to request an exact font face. If this property is undefined for a given element, the CSS1 font properties will be used to determine a font face.
If the element in question has no 'font-face' value, the UA will fall back onto the CSS1 properties to find a font. The CSS1 font properties can map to font descriptions. For this reason, CSS1 font properties are allowed inside font descriptions. To allow for many-to-one mappings, all these properties accept comma-separated lists as values inside the font description:
@font-face dull {
font-weight: bold, extra-bold, black;
font-style: italic, small-caps, small-caps italic;
src: url(http://font/stone/bold);
}
In the font description above there is no 'font-family' property and any font family value can therefor be mapped into this font description. Among the elements that will be mapped into this font description are:
<P STYLE="font-family: foo; font-weight: bold; font-style: italic"> <P STYLE="font-family: foo; font-weight: black; font-style: small-caps"> <P STYLE="font-weight: extra-bold; font-style: small-caps italic">Among the elements that will not be mapped into the above font description are:
<H1 STYLE="font-weight: medium;"> <H2 STYLE="font-weight: bold; font-style: oblique">As can be seen from these examples: for a given element to be mapped to a certain font descriptions through CSS1 properties, there must be no conflicts. In the above example, the H1 element will not be mapped since 'medium' is not in the list of weights in the font description. The H2 element will not be matched since 'oblique' is not in the list of font styles. Even if 'italic' is sometimes accepted as a synonym for 'oblique', this has no effect in mapping to font descriptions which always requires exact matches.
Using CSS1 properties along with font descriptions has one advantage over using the 'font-face' property: since the CSS1 properties are inherited, one do not need to set font values for all elements. E.g., a child 'B' element will most likely be displayed as the author expects without special treatment.
To be added.