Copyright © 1996-2022 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and permissive document license rules apply.
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.
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 https://www.w3.org/TR/.
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.
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.
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: http://www.w3.org/pub/WWW/TR/
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:
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.
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.
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.
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.
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.
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.
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).
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.
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.
This reduces down to having a URL for a font face resource.
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.
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!
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.
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.
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.
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