OpenType features in web browsers

This is a revised version of the original article published on 7 June 2012, updated to reflect the recent implementation of OpenType features in Chrome, and incorporating many corrections, clarifications and suggestions contributed by John Daggett (Mozilla), Paul Irish (Chrome) and readers. The changes in this revision have been summarized in a new section at the end of the text, and can be highlighted using the checkbox below.

show changes

Last updated on 5 July 2012.

---

The latest versions of all major web browsers now support the use of linked fonts in the OpenType format, either as ‘naked’ OpenType fonts, or wrapped in a WOFF container.

But while all modern browsers can display OpenType fonts, only Firefox (since version 4)[1], Internet Explorer 10 (preview version)[2] and the latest versions of Google Chrome[12] are currently able to display OpenType features. Each browser still requires a slightly different CSS syntax.

As the standardization process advances, it is expected that WebKit-based browsers (Safari, Chrome) Safari and Opera will also add support for OpenType features at some point.

W3C CSS3 Fonts specification

The CSS Fonts Module 3 CSS3 Fonts specification[3] published by the W3C is the place where the CSS syntax for font features is currently described and documented. It is edited by John Daggett (Mozilla), with input and contributions from other members of the WebFonts and Style CSS working groups.[4]

The specification is still in Working Draft[5] stage, with details being fine-tuned in parallel to the progress of implementations implementing them in browsers. The behaviour of superscript letters and numbers, for example, is one of the recent topics under discussion: Which superscript/subscript characters are commonly present in fonts, and which need to be synthesized by the browser? Should designed and synthesized characters be mixed in the same run of text? Should synthesized characters use the subscript/superscript metrics from the font, or those defined by user agents?[6] Fine-grained decisions like these can have a great impact on the behaviour of documents and the overall user experience. They need to be discussed by all browser makers, and standardized across browsers.

Work on the W3C CSS3 Fonts specification and related discussions can be followed via the public www-style mailing list, with separate discussions or cross-postings to the www-font mailing list.[7] There is no estimated date for the completion and final publication of the spec.

CSS syntax for OpenType features

The CSS3 Fonts specification offers two separate levels of control over OpenType features in fonts: high-level font-variant attributes, using human-readable names matching the terminology already used for other font-related CSS attributes; and the low-level font-feature-settings attribute, which uses OpenType’s 4-letter tags – for example smcp for small caps, onum for oldstyle numerals etc – to access font features directly.

The specification proposes high-level attributes as the main CSS mechanism for accessing font features.[8] But since their syntax and implementation details are still under discussion, these attributes are not yet fully supported by the latest releases of each browser.

Right now, the only way to use true OpenType features on the web is via the low-level font-feature-settings attribute. It gives access to most OpenType features, and is reasonably well supported by Firefox (since version 4), Internet Explorer 10 and the latest version of Google Chrome.[12].

Among major browser releases, only Firefox supports OpenType features (since November 2010).

High-level access to OpenType features

The proposed high-level CSS properties for font features include: font-kerning, font-variant, font-variant-ligatures, font-variant-position, font-variant-caps, font-variant-numeric etc. Each of these properties offers a pre-defined set of keyword options.

As an example, here is the syntax for activating both common and discretionary ligatures:

font-variant-ligatures: common-ligatures discretionary-ligatures;

Here we explicitly de-activate common ligatures, and activate only the discretionary ones:

font-variant-ligatures: no-common-ligatures discretionary-ligatures;

As noted above, this syntax is not yet supported consistently across the available browser implementations high-level CSS properties are not yet supported consistently in current browser versions. To access these features today, use the lower-level font-feature-settings instead. This situation is likely to change in the near future.

Low-level access to OpenType features

The low-level syntax for font features looks a bit more cryptic at first glance, but at the same time more is familiar to type-designers and users of OpenType fonts. With this mechanism, the font-feature-settings property is used together with 4-letter OpenType feature tags[9] to activate/de-activate each feature individually.

Here is the first example from above, rewritten using the lower-level CSS syntax:

font-feature-settings: "liga", "dlig";

Because Firefox was the first browser to implement support for font features, it still uses an older version of the syntax, and requires the vendor prefix -moz:

/* Firefox */
-moz-font-feature-settings: "liga=1, dlig=1"; 

Support for OpenType features in IE 10 came later, so the adopted syntax is up-to-date with the latest version of the spec. The first implementations used the vendor prefix -ms, but the latest release The first releases used the vendor prefix -ms, while the latest one has dropped it in favour of the unprefixed standard syntax.[10]

Work on the implementation of font-feature-settings in WebKit has been concluded recently, and is now available in Chrome (for all plattforms).[12] The current syntax follows the latest version of the spec (like IE 10), with the added ‑webkit prefix. The syntax for Opera is likely to be the same.

/* WebKit */
-webkit-font-feature-settings: "liga" off, "dlig";
/* Opera : not implemented yet */
-o-font-feature-settings: "liga" off, "dlig";

To make the example complete, here is a rewrite of the second high-level example from above, with standard ligatures turned off:

font-feature-settings: "liga", "dlig";
-moz-font-feature-settings: "liga=0, dlig=1";       /* Firefox */
-webkit-font-feature-settings: "liga" off, "dlig";  /* WebKit */
-o-font-feature-settings: "liga" off, "dlig";       /* Opera */

In a nutshell, this is the syntax needed to use OpenType features on the web today, considering the latest available releases of each browser. Not all features are accessible this way (see the table below for an overview), but the most common and useful ones are.

Because the official standard is still being written, all current implementations of OpenType features in browsers are experimental, and require the use of individual vendor prefixes.

The syntax for WebKit (Safari and Chrome) and Opera, when their implementations arrive, is likely to be the same as the one used by Internet Explorer, which is up-to-date with the latest version of the spec.

/* WebKit : not implemented */
-webkit-font-feature-settings: "liga" off, "dlig";

/* Opera : not implemented */
-o-font-feature-settings: "liga" off, "dlig";

At this point, these attributes have no effect in WebKit Safari and Opera, so don’t rush to add them to your stylesheets. We did include them in our tests pages though, to make them ready for the next batch of browser releases.

In the upcoming Firefox 15, the syntax for font-feature-settings will switch to the one described in the current draft of the CSS3 Fonts specification, still keeping the -moz prefix.[15] Once Firefox 15 is in wide use, the syntax across all browsers will finally match.

OpenType feature support in browsers

The table below gives an overview of the current state of OpenType feature support in web browsers. It is the result of a series of tests with both high- and low-level syntax schemes, using the latest versions of each browser.[11]

[Original table with test results per feature removed.]

Windows	✔	✘	✔	✔	✘
MacOSX	✔	✘	✔	—	✘
Linux	✔	—	✔	—	✘

Summary of research findings

The data in the table reveals the almost complete lack of support for OpenType features in WebKit browsers (Safari and Chrome). The delay for the implementation of OpenType features to arrive in WebKit is probably the main single factor holding back a wider use of OpenType features on the web today. But work is on its way, and recent activity in the WebKit tracker shows that this scenario will be changing soon.[12]

When the first version of this article was published, about one month ago, there was no support for OpenType features in WebKit, leading us to conclude that “the delay for the implementation of OpenType features to arrive in WebKit is [was] probably the main single factor holding back a wider use of OpenType features on the web today.” Within one month, this situation has changed considerably: WebKit implementation has been concluded, and OpenType features are now available to all plattforms in the latest version of Chrome.[12] This leaves us with only Safari and Opera lacking support for OpenType features.

The available implementations in Firefox and Internet Explorer are still experimental, so it was natural to find a few bugs and differences between browsers during the tests. (It was also a good surprise to see a few of these bugs disappear with newer builds.) Some of the issues observed are worth mentioning:

1. In Firefox, it is not possible to turn off default ligatures (liga).
2. Use of Localised Forms (locl) in combination with the lang tag does not work in Internet Explorer 10. Historical Ligatures (hlig) are also not displayed.
3. Ordinals (ordn) and Oldstyle Figures (onum) don’t work in Firefox.

Tests for Contextual Alternates (calt) revealed a few surprises, with different results not just between different browsers, but also between different fonts. Interestingly, this feature is supported by Chrome (inconsistently, with differences between fonts). In Firefox, the feature is either ‘on’ or ‘off’ depending on the font, and its state cannot be reversed. At this stage, only IE 10 supports calt correctly.

Kerning in webfonts is in a big mess at the moment. As if it were not enough to have two kinds of kerning data in OpenType fonts (the kern table and the kern OpenType feature), we now also have 3 different ways of accessing (OpenType) kerning data in fonts with CSS: via the high-level font-kerning property, the low-level font-feature-settings:'kern', and the WebKit-specific property text-rendering:optimizeLegibility. To make matters worse, the amount of kerning applied is different depending on the browser.

Kerning (kern) and standard ligatures (liga) are the only features which currently work in all browsers (except Opera), thanks to the WebKit-specific property text-rendering. This property is not part of the CSS3 Fonts standard, and activates more than one feature at once – so it should be deprecated in favour of the individual properties defined by the spec as soon as they become available.

On a positive note, the OpenType features needed to display Arabic text – rlig, mark, fina, init, isol and medi – are already supported in all browsers (including Opera 12). More tests are needed to show if the same is true for Indic scripts.

The greatest disappointment of the research was Opera’s performance, with zero support for latin OpenType features. This was a bit surprising, given Håkon Wium Lie’s founding role in CSS and long-term engagement in turning the web into a more powerful publishing platform, including early advocacy for webfonts.[13] Let’s hope that Opera (and WebKit Safari) catch up soon.

One important finding – made only after the initial publication of this article and the tests – is that the OTS library[14] used by Firefox and Chrome to validate linked fonts is stricter than other commonly used libraries and applications. Depending on the severity of the problem, OTS can drop specific tables (causing the features controlled by them not to work), or reject fonts altogether. The same fonts and features work fine in other applications, such as those in the Adobe Creative Suite, IE10 or FeatureProof. While it is understandable that browsers are stricter with font security issues than desktop applications, it is a problem that fonts which so far, for all practical purposes, have been considered valid, start to malfunction. Inconsistency between applications means an increase in the amount of support calls from users, forcing font makers to review their font libraries and release updates fixing the problems. Looking at the issue from this perspective, it would be preferable if the behaviour of OTS were consistent with that of other apps: quietly work around the error and, instead of rejecting whole tables, try to recover their data so that the features work as intended.

Our tests and the subsequent conversations with browser makers also brought to light a subtle but important difference in how browsers handle defaults. In OpenType layout, there is a defined set of features which are ‘on’ by default for a given script. In Firefox all text is rendered with these defaults on, while in WebKit and IE the default behavior is to render text with a ‘fast path’ layout, in which only glyphs and advances are used and no shaping (either substitutions or positioning) occurs. WebKit and IE only enable default features when something triggers the use of complex text rendering – for example a non-default value for font-feature-settings.[16] Sadly for users, browser makers have not yet agreed on a standard default behaviour for OpenType text shaping, so we still need to deal with inconsistencies across browsers.

Conclusion

It is important to underline that this article and our testing methods focus on a near-future scenario, using the latest public beta versions of each browser. The results shown in the table do not yet reflect the experience of the web audience at large, since most users are still running older versions of each browser. This scenario does not yet reflect the experience of the web audience at large, since most users are still running older versions of each browser.

For the moment, the only way to provide access to rich typographic features for users of all web browsers is to fallback to single special fonts – like in the old days, before the advent of OpenType. Web font services such as Typotheque’s do not yet include font features in webfonts by default, but instead offer a convenient interface for setting up the right styles and features, and generate the individual files and CSS automatically behind the scenes. In the future, such a system will be able to use a single font file, and toggle OpenType features on/off with pure CSS.

Despite its immense readership and relevance today, the web – with its standard technologies HTML/CSS/JS – is still a rather primitive medium for typography. It still misses features which we take for granted in other publishing environments, from commercial and free desktop publishing applications to typesetting systems like TEX: hyphenation and pagination, layout and indexation tools, templates, grids, integrated annotations etc.

All of this is known, and much is being done by the W3C to improve these sub-systems: responsive images, CSS Grids and Regions, and CSS variables are a few examples of ongoing projects advancing in parallel to CSS3 Fonts. It just takes some time for all the pieces to go through the proper standardization channels and become available to all users.

Even if we had full support to OpenType features on the web today – the OpenType layout model also has known limitations and boundaries. The truly interesting questions surrounding web and screen typography lie beyond the scope of the OpenType format. Let us spend more time thinking and talking about that, and less about specific technologies and formats.

Notes

1. See Firefox 4: OpenType font feature support, November 2010.

2. See CSS Corner: Using the Whole Font, January 2012.

3. CSS Fonts Module Level 3, W3C Working Draft 4, October 2011.

4. The WebFonts Working Group is responsible for the specification of the WOFF format, while the Style Working Group is responsible for CSS as a whole.

5. See W3C recommendation: Working Draft (WD), Wikipedia.

6. For a complete description of the issues around subscript/superscripts and webfonts in CSS, see John Daggett’s original message to the www-font list.

7. Both lists are public, and their archives are available online: see www-font mailing list and www-style mailing list.

8. Authors should generally use ‘font-variant’ and its related sub-properties 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. See 6.12 Low-level font feature settings control: the font-feature-settings property, CSS Fonts Module Level 3.

9. See the OpenType Layout tag registry, maintained by Microsoft.

10. See the section “Vendor prefixes, and moving the Web forward from experimental to stable” in Windows Release Preview: The Sixth IE10 Platform Preview, June 2012.

11. Firefox 13.0, Chrome 22.0, Safari 5.1, Internet Explorer 10 (Preview), Opera 11.64/Opera Next 12.00. Part of the tests was made with help from BrowserStack, a live web-based cross browser testing tool. The structure of the table was changed in the revision to cover browsers × platforms, instead of browsers × features as in the original article.

12. Searching in the WebKit tracker, one can find patches from 2011 enabling text shaping with font-feature-settings on Linux, using the HarfBuzz library, and on Windows, using Uniscribe. The missing implementation for the Mac is also on its way. It is not clear at this point if it will use the native CoreText library, or HarfBuzz. The implementation of OpenType features in WebKit has been concluded between the initial publication of this article and the current revision, and is now available in Google Chrome 22.0 (Canary).

13. See, for example: CSS @ Ten: The Next Big Thing (2007), Prince XML: Generating High Quality PDFs from HTML+CSS (2007, with Michael Day) and CSS3 (Fronteers Conference, 2010).

14. OTS (Sanitiser for OpenType), a small library which parses OpenType files (usually from @font-face) and attempts to validate and sanitise them.

15. During the transition period, the following syntax can be used:

-moz-font-feature-settings: "liga=1";  /* Firefox 14 and before */
-moz-font-feature-settings: "liga" on; /* Firefox 15 */

For Firefox 15 and above, the first line will result in a syntax error, and the second line will be used. In Firefox 14 and before, the on keyword in the second line will cause a parse error, and the first line will be used. If only liga with no keyword is used, no parse error occurs in Firefox 14 and before, and the setting will be ignored.

16. In WebKit, complex text rendering with the appropriate defaults can also be triggered with text-rendering:optimizeLegibility. This property is not part of the CSS3 specification.

Revision Notes

Below is a summary of the main changes in relation to the original text.

1. The approach used to present the test results was considered inappropriate, since it suggested that OpenType features were implemented individually by browsers, when in fact (in most cases) they are implemented all at once by a shaping library. At the same time, the important distinction between Window/OSX/Linux was missing. As a result, the table structure has been completely redesigned in the revision.

2. The initial tests produced negative results for specific features in Firefox (onum, ordn). As it turned out, this was caused by problems in the fonts, which led to some of the tables being dumped by OTS (Sanitizer for OpenType). The text has been corrected, and a few notes about OTS have been added.

3. The preferred name of the specification mentioned throughout the article is CSS3 Fonts, and not W3C Fonts or CSS Fonts Module 3 as used originally. This has been corrected in the revision, together with a few other W3C-related terms.

4. Between the publication of the original article and the current revision, OpenType features have been implemented in WebKit and shipped with Chrome.[12] The table, the CSS samples and the text have been updated to reflect this fact.

Thanks to John Daggett and Karsten Lücke for detailed comments on previous versions this text.