Fonts for the Web: Rationale, 1996

W3C Group Note

More details about this document
This version:
Latest published version:


This is a requirements document dating to 1996, created at the start of work on Web Fonts at W3C by the Web Fonts Working Group, which is now being published as a matter of historical record.

Status of This Document

This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at

This document was published by the Web Fonts Working Group as a Group Note using the Note track.

Group Notes are not endorsed by W3C nor its Members.

This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

The W3C Patent Policy does not carry any licensing requirements or commitments on this document.

This document is governed by the 2 November 2021 W3C Process Document.

Historical Context

On April 25, 1996, W3C held a one-day workshop on high quality printing from the web. Several position papers for that workshop suggested the need for improved typography on the Web, including:

In response to this, and following discussions at the workshop, interested parties were encouraged to subscribe to an informal mailing list to facilitate discussions. This grew into the Web Fonts Working Group, chaired by Chris Lilley, which on 1 July 1996 produced a set of requirements, reproduced below. The intention was to make this document public — the document states “This is (soon to be) a W3C Working Draft” — but sadly it was only ever published as a W3C Member-only document while the Working Group focus turned towards designing technology which would meet those requirements.

On 21 July 1997, the first public draft of Web Fonts was released, introducing the now-familiar @font-face CSS mechanism for downloadable fonts. This work was then merged into CSS2, which became a W3C Recommendation on 12 May 1998. However, not until 2010, with the first draft of Web Open Font Format (WOFF) 1.0 would downloadable web fonts start to become a dependable and widely used reality. For further information on the history, current deployment, and challenges of Web Fonts, the interested reader is directed to Webfont deployment - successes, problems, solutions.

In 2022, the work of the W3C Web Fonts Working Group — together with MPEG, which standardizes Open Font Format, also known as OpenType™ — was honored with a Technology & Engineering Emmy® Award. Reflecting back on 25 years of work in the area, the Working Group resolved to make this, their earliest Web Fonts requirements document, available to the public as originally intended.

Original (1996) requirements document


Fonts for the Web: Rationale

W3C Working Draft 01-July-1996

This version:
Latest version:

Status of this document

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". A list of current W3C working drafts can be found at:

Note: Since working drafts are subject to frequent change, you are advised to reference the above URL, rather than the URLs for working drafts themselves.


The goal of the W3C working group on fonts is to produce recommendations for open font solutions for the web. Issues to be resolved include, but are not limited to: style sheet notation, client-server request structure, font matching and synthesis information, and font location.

This document describes the goals of the W3C Font Working Group so that the design philosophy is clear. It includes examples of different scenarios where fonts might be used on the Web, and also has a glossary of terms.

Another document describes the abstract information needed to describe fonts for matching, synthesis, or requesting a font over the Web. A third document binds font descriptions to HTML and CSS-1. Bindings to other media, for example to VRML, to CGM, or to Java, are also possible.


The following list of goals is not in order of importance. Each item is linked to a fuller description:

  • Open
  • Both html & non-html issues
  • Fall rollout
  • On the fly generation possible
  • Document local fonts possible
  • Mechanisms for IPR protection (author, user agent)
  • Minimal net traffic/latency
  • Enable progressive layout
  • Font selection by name
  • Font data access (& reference)
  • Font synthesize substitution
  • Cross platform support
  • Minimize use of images for typography
  • Not require new font purchases
  • Enable browsers to do ligatures & contextual forms
  • Open

    We should not require proprietary technology, and the solution must not be restricted to a single or limited number of technologies. We do not know what file formats or compression schemes will be used, and cannot predict all font technologies that might exist in the future.

    Thus, a solution for Fonts on the Web should be a framework, capable of supporting current and future technologies (based on content negotiation between a knowing and willing sender and recipient), and be implementable from publically available specifications.

    Both HTML & non-HTML issues

    Although the initial focus of our work is the use of Fonts in HTML, the solutions should be sufficiently general that other media can re-use relevant parts of our specifications. Ideally, if a particular web font was requested by an HTML document, should be re-usable by (say) a Java applet which calls for the same font, without having to fetch it again.

    Fall (autumn) roll-out

    We plan to work fast, producing specifications before versions of browsers are released that incorporate the new font capabiliites. The first rough draft to be available in early July, with a stable draft by early August (ready, perhaps, for public exposure on the W3C TR list at this point?) Of course the work does not stop there; test implementations and proofs of concept are needed, the specifications get polished and dis-ambiguated; we issue press releases; the drafts move through to publication, the final versions are implemented in browsers and authoring tools.

    On the fly

    Increasingly, documents are automatically generated. It should be possible for multiple independent scripts to each generate (parts of) an HTML document which uses Web Fonts, without requiring random access editing at the time of document generation; simple concatenation should suffice.

    Document local fonts possible

    It should be possible to reference fonts whose lifetime and accessibility is limited to the displayed document. It the fonts have names, these should not match any fonts installed on the client.

    Mechanisms for IPR protection

    There was agreement on the desirability of mechanisms for enabling fair play on Intelectual Property Rights issues. This was seen as a first step, and preferably to promising cast-iron protection against theft which it was noted would require strong encryption technology.

    Mimimal net traffic / latency

    It should be possible to avoid getting the same font multiple times (in particular, the same font should not need to be obtained on each repeated download of the same document). This benefits individual users, in that they see the completed document quicker; it also benefits the net as a whole by minimising total bandwidth use. The aim is to be cache freindly, and also to be replication-freindly.

    Latency may be reduced by progressive rendering, and may also be reduced at the user's option by disabling downloading of Web Fonts (in the same way that may browsers permit disabling of inline image downloading).

    Enable progressive layout

    Provide the means so that authors who want it, and browsers that support it, can add the data needed for progressive layout whereby the font is rapidly synthesised during font data download, and the line breaks don't change when the real font comes in. It was noted that tables of glyph widths provide no help with kerning, so lines (especially headlines) will get shorter once the real fonts arrive.

    Font selection by name

    Fonts should be referenced by name, for example "Tekton" rather than by some meaningless identifier, for example "84fvo325z2356". This raises the issue of exactly what is mean by a font. The font name should reference a single font file, not a styled family of four (unless of course, we can come up with a common scheme that works across platforms. It seems that we mean a particular face of a font, or some subset of it, for example "Bodoni Medium Italic". This may mean a font collection, for example latin, cyrillic and greek glyphs in three font files, forming a single face of a multilingual font; or two font files, latin characters plus small-caps and old style figures, forming a complete glyph repertoire of a single font face.

    Font data access ( & reference)

    This reduces down to having a URL for a font face resource.

    Font synthesis / substitution

    Strongly tied to progressive rendering, but more a strategy for situations where the font data cannot be fetched over the net. Where supplied by the document author, font description and metrics should be able to drive font synthesis (Infinifont, Chameleon, etc.) and substitution (PANOSE) engines.

    Cross platform support

    The proposed solution must be independent of font platform, browser platform and media type (Page Description Language). This is clearly needed - click here for the mac version, yeuck!

    Minimise use of images for typography

    Currently all quality typography on the Web uses inline images. If sending an image is smaller, faster, causes less platform headaches, and is devoid of IPR issues, then our solution will go unused. We should support as many standard typographic features as we can. While we probably cannot eliminate all usage of images to fake text - there is always one more effect - we can sure go for the 80/20 rule so that the font solution becomes the norm.

    Not require new font purchases

    Authors should own the fonts and browsers should protect IPR. New purchases should not be required, in that font purchases in existing formats should be usable provided the license permits such use; but our solution need not eliminate the need for new purchases either. Users should be able to use their own installed fonts (at least when using font substitution). The time and effort neccessary to extract new fields from existing font files should be kept to a minimum.

    Enable browsers to do ligatures & contextual forms

    An HTML document is a marked-up sequence of characters. It is not a list of indexes into a font. HTML remains character-, not glyph-oriented. Thus, ligatures and contextual forms will be left to the type technologies (such as OpenType), rather than supported via our Web font descriptors.

    For many European languages, there is in most cases a one-to-one maping between characters and glyphs; so this distinction is only seen when, for example, someone inserts a code for an 'fl' ligature (and then discovers that the search engines are unable to index the document correctly). This has particular implications for scripts such as Arabic, which has four different glyphs for each character even without taking into account the ligatures required.

    This also implies that some other data may be needed (the lang attribute in HTML is an obvious example). It has implications when glyph subsets of a font are requested.



    Adorned Font Name
    An Adorned Font Name is the name of the font as reported by the operating system and as it appears within most menus. Adornments such as bold, italic, underline are usually used to select the appropriate font within a font family.
    the author of an HTML document
    Character Set Sub-setting
    Character set sub-setting is the process by which a smaller set of characters are removed from a primary font with the result being a smaller font. The primary objective is to reduce the number of characters to a subset that covers a particular document or set of documents.
    Cascading Style Sheets, level 1.
    A font is a collection of glyphs according to design, size, appearance, writing system, and other attributes associated with the entire set.
    Font Caching
    Font caching allows for a temporary copy of fonts on the client system. They are usually strored on disk with other cached items such as graphics specifically for the browser.
    Font Data
    The data that defines the glyphs of a font, most often glyph outlines.
    Font Description
    A description of a font, but without the actual glyph shapes. The level of detail can vary from just the name of the font up to a list of glyph metrics.
    Font Face
    A "handle" that refers to a specific face of a font, excluding the font size (? size may be needed for non-scalable fonts)
    Font Matching
    Font matching is a process of selecting a similar font based on using one or more attributes of the primary font. Common attribute include serif, sans serif, weight, cap height, x height, spacing, language, and posture. Font matching is dependent on the algorithm and the variety of candidate fonts.
    Font Reference
    A network request for a certain font face from a document
    Hypertext Markup Language, an application of SGML.
    Multiple Master Font
    A Multiple Master Font contain two primary fonts that are used with special rendering software to provide an interpolated result. Adobe Systems provides a mechanism that allows for parameters to be used to control the output or the interpolated output font. These parameters usually describe the characteristics of an original font and the multiple master result is referred to as a synthesized font.
    Panose-1 is an industry standard TrueType font classification and matching technology. The PANOSE system consists of a set of numbers that categorizes the key attributes of a typeface, a classification procedure for creating those numbers, and Mapper software that determines the closest possible font match given a set of typefaces. Panose technology was originally developed by Elseware Corporation and is now owned by Hewlett Packard.
    Progressive rendering
    Progressive rendering of fonts is the blending of a substitute font which approximates the look while matching the metrics of the original font, while waiting for the actual font to be retrieved from a server and rendered. Progressive rendering requires metric information about the font in order to avoid re-layout of the content when the actual font has been loaded and rendered. This metric information is sufficiently verbose that it should only be specified at most once per font in a document.
    The person for whom the document is rendered
    Server Font
    A Server Font is a font resource located on the web server that is referenced by the WebFont definition. The user agent may use this resource for rendering the page.
    TrueDoc technology was developed by Bitstream specifically for the creation, transport, and imaging of platform independent scaleable font objects on the web. Creation of font objects is done by the TrueDoc character shape recorder (CSR) and the rendering of the font objects is done by TrueDoc's character shape player (CSP). The technology is intended to be used on the web for viewing and printing.
    TrueDoc Portable Font Resource
    A TrueDoc Portable for resource (or PFR) is a platform independent scaleable font object which is produce by a character shape player. Input may be either TrueType or Type 1 of any flavor on either Windows, Mac, or Unix. TrueDoc Portable Font Resources provide very good compression ratios, are platform independent, and because they are not in an native font format (TrueType or Type 1) they can not be easily installed.
    TrueType is a font format developed by Apple and licensed to Microsoft. TrueType is the native operating system font format for Windows and Macintosh. TrueType contains a hierarchical set of tables and glyphs. Characters can be hinted on a per character and point size basis yielding excellent quality. TrueType fonts for Windows, Mac, and Unix have few differences, however there are different enough to prevent cross platform usage. Font foundries provide TrueType fonts for each platform and usually include a license preventing electronic manipulation to achieve cross platform transparency.
    TrueType Collection
    A TrueType Collections (or TTC) is an extension to the TrueType format that includes tables that allow for multiple TrueType fonts to be contained within a single TrueType font file with the extension .ttc. TrueType collection files are relatively rare at this time.
    TrueType GX Fonts
    TrueType GX Fonts contain extensions to the standard TrueType format that allow for mutable fonts, similar to multiple masters . There may be several mutation axis such as weight, height, and slant. The axis can be defined to obtain almost any effect. TrueType GX can also supports alternate glyph substitution for ligatures, fractions, logo, etc. To date, TrueType GX is available only on the Mac.
    Type 1 font
    Type 1 fonts, developed by Adobe Systems, were one of first scaleable formats available. Type 1 fonts are usually contain 228 characters with the glyphs described using third degree bezier curves. Mac, Windows, and Unix have their separate formats and Adobe provides Adobe Type Manager for all three platforms.

    Retrospective analysis

    This requirements document reflects the state of consensus a few months after the workshop. Licensing, Intellectual property Rights (IPR) and enforcement were hot topics; it was widely believed that using fonts on the Web was tantamount to open piracy and even he idea of using outline fonts rather than pre-rendered bitmaps was controversial. So “Minimise use of images for typography” was a bold statement at the time.

    It is interesting that a CSS-based linking mechanism was generally preferred, although (CSS being a totally new technology at the time) some preferred a link element in HTML. Some decades later, linking fonts from HTML resurfaced, as a preload mechanism.

    There was some confusion over existing font licenses and whether they did or did not allow online use. Over time, once WOFF was released which allowed a link to the license, there was a move for commercial fonts to offer a choice of clear print-oriented or web-oriented licensing, rather than making a single license applicable to both situations. For libre fonts, clear licenses like OFL became popular. In retrospect, the problem here was primarily that existing licenses were vague and uinformative for any use other than commerical printing.

    There was a dawning awareness in the mid 1990s that characters and glyphs were not the same thing and thus, that ligatures, contextual forms, and the like were properly the domain of fonts and text rendering systems and should not be showing up in HTML content. Not until June 2018, with CSS Fonts 3, however, would the full power of OpenType font features be available on the web, which lagged behind the capabilities of print media for some decades. (One of the popular formats at the time, TrueDoc PFR, assumed a 1:1 correspondence between characters and glyphs). In retrospect, that distinction would prove vital to further develoment of fonts on thw web.

    At the time, intelligent font substitution and font synthesis were interesting topics largely driven by the slow network speeds of the time. In retrospect it proved more difficult to synthesize a look-alike typeface than had been anticipated, and as download speeds improved, there was more emphasis on downloading the correct font and less on simulating it.

    It is interesting that “Font selection by name” was a goal. There are two models of funt usage for structured documents; one where the complete font face is specified on every element, and one where font families, font weights, and so on are separately inherited down a document tree. CSS 1, and more so CSS 2, took the latter route.

    The aim of reducing latency by agressive font cacheing was notable, although the twin aims of security from cross-site scripting and guarding the privacy of the user have largely negated such gains in contemporary web practice.

    The passing mention of TrueType GX is, in hindsight, an interesting herald of the current growing importance of variable fonts in responsive web design