Toward a standard font size interval system

Todd Fahrner, Verso

The simplest things are the most important and hardest.

  1. Abstract
  2. The problem
  3. The legacy solution
  4. The CSS challenge

Abstract

This document proposes a unified scheme for displaying font size ranges on screen in a predictable, attractive, user-centric fashion, regardless of screen resolution or fonts in use (mostly). This scheme will enhance the legibility, clarity, and aesthetics of Web documents, and promote the evolution of the Web as a visually rich medium that remains dynamic, lean, and accessible to users with special requirements, devices, or handicaps.

Harmonizing Cascading Style Sheets' seven "keyword" sizes with the Web's legacy font size interval systems, this proposal is intended for Web browser developers of all religions, but may be of interest to digital typography and/or CSS enthusiasts in other fields.

If you think the subject matter is important, and disagree or don't understand, please either contact me or bring it up in an open forum such as the W3C's www-style mailing list.

The problem

Generalities

Font size modulation is a fundamental typographic design technique. Size does matter. A reader can discern the structure of documents at a glance when their internal structure is reflected (among other things) by relative font size changes. Larger type is for headings or emphasis, smaller type is for deemphasis, and medium type is, well, medium. In high-resolution print typography, designers enjoy considerable freedom and control over the articulation of this range. In low-resolution screen typography, designers don't.

There are many problems associated with displaying arbitrary font size ranges distinctly and attractively at low screen resolutions. Apart from the impact of font substitution, for which a solution has already been recommended, arbitrary or ill-conceived font size interval differences across applications or platforms (i.e., on the World Wide Web) often interfere unacceptably with the accessibility, logical clarity or aesthetics of documents.

While the problems are subtle in nature, they are profound in effect: people often can't read on screen, or can read only with discomfort. Even when legibility per se is not impaired, most on-screen textual display remains either extremely crude, or styled by desperate or naive designers with inflexible pixel or print-specific units such as points or inches. In the worst case, the designer will simply turn most or all text into graphics. This is akin to treating a headache with a guillotine.

Specifics

Users require or prefer different base font sizes on screen depending on the font design, their vision, their equipment, their environment or purpose, their taste, and maybe the time of day. So it's a good idea (maybe even the law) for Web designers to let users stay in charge of the size of "medium" text, and to specify the size of larger and smaller elements in terms relative to medium. Specifically, the Web Accessibility Initiative's guidelines recommend the use of "em" or percentage lengths rather than absolute lengths such as "pt" or "cm".

Common browser bugs aside, specifying larger sizes in relative length units through CSS is seldom problematic. Specifying smaller sizes, however, can be hazardous. If the user's chosen size of "medium" text is itself too close to the legibility floor, any smaller size specifications may become illegible.

Specifying very cautious decrements such as "95%" may produce no visible change, or "kink" the low end of the ideally continuous font size scale apparent throughout the document. The more steps below "medium" are required, the more acute the dilemma.

Furthermore, the proper use of relative length units such as "em" or "percent" can be deceptively difficult when document elements are nested. For example, if document divisions are styled through CSS to be at "80%" size, all may appear to be well until a division is itself divided. Since relative length units refer to the size of the parent element, the size of the nested division should then be the compound: 64%. And if that division contains divisions?

This is div 1
This is div 2
This is div 3

Assuming a progressive reduction is not intended, it is possible to write stylesheet rules with contextual selectors to compensate, e.g.:

div { font-size: 80% }
div div { font-size: 125% }
div div div { font-size: 100% }

The complication of such an approach is generally prohibitive. The problem might also be circumvented by using class or id selectors instead of an element selector, but this assumes that the stylesheet author is free to modify the document: an increasingly invalid assumption given the growing respect for documents as data, as evident in the rise of XML. Besides, even contextual and/or class selectors fail in the face of a deeply entrenched bug: selective inheritance of font style into tables.

The convention of resetting certain font styles to their defaults when the document parse tree happens to branch into tabular elements http://www.w3.org/TR/REC-CSS2/cascade.html#inheritance .eployed in haste by Netscape in 1995, painstakingly copied by Microsoft shortly thereafter, corrected by the Internet Explorer team for MacOS and by Opera, fixed in development versions of Netscape 5.0, yet perversely enshrined to this day by the Internet Explorer team for Windows: font style inheritance into tables.

It is beyond the scope of this piece to plumb this entomological pathology in depth, but a live demonstration should suffice.

The legacy solution

The solution is for the designer to specify sizes not in any length system - relative or absolute - but in literals whose actual values adapt intelligently to the given value of "medium". Neither the problem nor the solution are new: Netscape included it in its original implementation of size attributes on the now-deprecated FONT element. The scaling interval between steps in this system varies nonlinearly along the scale, depending on the pixels-per-em value of "size 3" chosen in the user preferences (medium):

16ppem - 12pt@96ppi
(Windows UA default)
16ppem - 12pt@96ppi (Windows UA default)1-3 interval: 60%
12ppem - 12pt@72ppi
(legacy MacOS UA default)
12ppem - MacOS default1-3 interval: 75%
live Font size=7
Font size=6
Font size=5
Font size=4
Font size=3
Font size=2
Font size=1
1-3 interval: varies with pixels-per-em
of your choice of "3" (user's default)

In the HTML font size interval system as implemented in mainstream browsers, if the user's medium has 16 pixels per em, then size 1 is 60%, or 10 pixels; however, if the user's medium has 12 pixels per em , then size 1 is 75%, or 9 pixels. This helps assure that the value of "1" doesn't drop below the minimum legible size of 9 pixels, while allowing the slope to steepen and the floor to rise for higher pixels-per-em at medium.

Pixels per em is a crucial concept. As much as any other single factor (such as ex-height), it determines the legibility of characters on screen at a nominal point size. The higher the ppem, the better defined are the characters' features, and the more and larger decrements are possible before hitting the legibility floor. If the ppem of the base size is low, fewer and smaller steps are possible.

Pixels-per-em refers to the number of screen pixels required to render the em of a font at a size given in points.

A point is 1/72". On a system displaying 72 pixels per inch (Mac OS standard), 1 point equals 1 pixel. On a system displaying 96 or 120 ppi (standard Windows settings), 1 point equals 1.333 or 1.667 pixels, respectively. The formula for ppem is a(b/72), where a is the font size, and b is the logical resolution figure.

For example, 12 points at 72 ppi (the legacy Mac OS browser default) or 9 points at 96ppi have a ppem value of 12. 12 points at 96ppi (the legacy Windows browser default), or 16 points at 72ppi both have a ppem of 16. 12 points at 90ppi have 15ppem, and 12 points at 120 ppi (Windows "large fonts") have 20ppem.

This obscure, sophisticated behavior supports not only the usability of the FONT element, but also governs the sizes of headings H1-H6, as well as the BIG and SMALL elements. The popularity of HTML's font size attribute attests to its effectiveness. Valuable and ill-documented, it is in danger of being lost.

The CSS challenge

CSS putatively supersedes the HTML font sizes with absolute size keywords of its own:

xx-small x-small small medium large x-large xx-large

It is unclear whether CSS's seven keywords were intended to map directly to the previously implemented seven HTML size values, but such a mapping would clearly facilitate the transition to CSS, lower implementation costs, and preserve the benefits of the adaptive behavior described above. Unfortunately, no simple mapping is possible.

Note that in the CSS scale, "medium" is in the middle, while the HTML size scale is asymmetric. The CSS scale has three rather than two steps below medium. The algorithm or data set that governed the sizes of the HTML font sizes is inadequate to the CSS scale. Implementing the CSS scale in a usable manner while maintaining consistency with the earlier model is therefore an important problem. The systems must be harmonized to preserve the intuitive correlation of CSS's "medium" with HTML's "3", and support three sizes distinctly and legibly below medium for any reasonable base value.

The CSS specifications don't spell out any correlation strategy; in fact, they suggest poor ones. CSS-1 suggested a disastrously high 1.5 interval between indices. Netscape 4.x implemented this, making the keywords unusable in practice (even "small" comes out to the illegible 8px when "medium" has 12ppem, and xx-small is less than 4px). CSS-2 amends CSS-1 to suggest a 1.2 scaling factor, but this factor still produces illegibly small results for either x-small and xx-small when medium has any ppem value lower than 15.

The CSS specifications' suggested scaling factors thus unwittingly discourage user selection of a medium font size at any value significantly below the Windows Mosaic default (12 points at 96ppi). Any single scaling factor, finally, is inferior to and incompatible with the more sophisticated legacy system.

Harmonization

Note: Below is a large table styled extensively with CSS. It is known not to display with a useful degree of accuracy in any released version of Netscape Navigator/Communicator. I have certified adequate font size rendering accuracy only in recent versions of MS Internet Explorer. If in doubt, see this big GIF version (1297x1078; 133K) instead.

CSS absolute size keywords: xx-small x-small small medium large x-large xx-large  
CSS relative size keywords:
(de/in)crement from base
    << smaller/larger >>      
HTML absolute font sizes:
(interpolated Mozilla values)
1   2 3 4   5   6 7
HTML relative font sizes:
(de/in)crement from base
    << +/- n >>          
HTML small/big:
(de/in)crement from base
    << small/big >>          

 

CSS absolute size keywords: xx-small x-small small medium large x-large xx-large  
HTML absolute font sizes:
(interpolated Mozilla values)
1   2 3 4   5   6 7
HTML headings:
(interpolated Mosaic values)
h6   h5 h4 h3   h2   h1  
HTML headings:
(proposed improvement)
  h6 h5 h4 h3 h2 h1  
normalized scaling factor: 60% - 3:5 75% - 3:4 89% - 8:9 100% - 1:1 112% - 9:8 125% - 5:4 150% - 3:2 167% - 5:3 200% - 2:1 300% - 3:1
px computed from a 20 ppem base:

e.g., 12pt @ 120ppi or 15pt @ 96ppi
(cf. Windows' "large fonts")
12px

Épe
Épe
Épe
Épe

15px

Épe
Épe
Épe
Épe

18px

Épe
Épe
Épe
Épe

20px

Épe
Épe
Épe
Épe

22px

Épe
Épe
Épe
Épe

25px

Épe
Épe
Épe
Épe

30px

Épe
Épe
Épe
Épe

33px

Épe
Épe
Épe
Épe

40px

Épe
Épe
Épe
Épe

60px

Ép
Ép
Ép
Ép

px computed from a 16 ppem base:

e.g., 12pt @ 96ppi or 16pt @ 72ppi
(XP 5.0 UA default)
10px

Épe
Épe
Épe
Épe

12px

Épe
Épe
Épe
Épe

14px

Épe
Épe
Épe
Épe

16px

Épe
Épe
Épe
Épe

18px

Épe
Épe
Épe
Épe

20px

Épe
Épe
Épe
Épe

24px

Épe
Épe
Épe
Épe

27px

Épe
Épe
Épe
Épe

32px

Épe
Épe
Épe
Épe

48px

Ép
Ép
Ép
Ép

px computed from a 15 ppem base:

e.g., 12pt @ 90ppi or 11pt @ 96ppi
9px

Épe
Épe
Épe
Épe

11px

Épe
Épe
Épe
Épe

13px

Épe
Épe
Épe
Épe

15px

Épe
Épe
Épe
Épe

17px

Épe
Épe
Épe
Épe

19px

Épe
Épe
Épe
Épe

23px

Épe
Épe
Épe
Épe

25px

Épe
Épe
Épe
Épe

30px

Épe
Épe
Épe
Épe

45px

Ép
Ép
Ép
Ép

compensated scaling factor: 63% - 5:8  
px computed from a 14 ppem base:

e.g., 12pt @ 84ppi or 14pt @ 72ppi
9px

Épe
Épe
Épe
Épe

11px

Épe
Épe
Épe
Épe

12px

Épe
Épe
Épe
Épe

14px

Épe
Épe
Épe
Épe

16px

Épe
Épe
Épe
Épe

18px

Épe
Épe
Épe
Épe

21px

Épe
Épe
Épe
Épe

23px

Épe
Épe
Épe
Épe

28px

Épe
Épe
Épe
Épe

42px

Ép
Ép
Ép
Ép

compensated scaling factor: 67% - 2:3  
px computed from a 13 ppem base:

e.g., 12pt @ 78ppi or 10pt @ 96ppi
(cf. X-windows' "75ppi" bitmaps)
9px

Épe
Épe
Épe
Épe

10px

Épe
Épe
Épe
Épe

12px

Épe
Épe
Épe
Épe

13px

Épe
Épe
Épe
Épe

15px

Épe
Épe
Épe
Épe

16px

Épe
Épe
Épe
Épe

20px

Épe
Épe
Épe
Épe

22px

Épe
Épe
Épe
Épe

26px

Épe
Épe
Épe
Épe

39px

Ép
Ép
Ép
Ép

compensated scaling factor: 75% - 3:4 83% - 5:6  
px computed from a 12 ppem base:

e.g., 12pt @ 72ppi or 9pt @ 96ppi
(MacOS pre-5.0 UA default)
9px

Épe
Épe
Épe
Épe

10px

Épe
Épe
Épe
Épe

11px

Épe
Épe
Épe
Épe

12px

Épe
Épe
Épe
Épe

13px

Épe
Épe
Épe
Épe

15px

Épe
Épe
Épe
Épe

18px

Épe
Épe
Épe
Épe

20px

Épe
Épe
Épe
Épe

24px

Épe
Épe
Épe
Épe

36px

Ép
Ép
Ép
Ép

Pixel values of CSS absolute size keywords


http://www.w3.org/TR/REC-CSS2/fonts.html#x18 


http://css.nu/articles/typograph1-en.html



    5       xx   xxx  xxx
    4     xx  xx   x  x
    3     xxxxxx    xx
    2     xx       x  x
    1       xxx  xxx  xxx


1. W3C Web Accessibility Guidelines:
     "Use relative rather than absolute units in markup language attribute
      values and style sheet property values. [...] For example, in CSS, use
     'em' or percentage lengths rather than 'pt' or 'cm', which are absolute
      units."

http://www.w3.org/TR/REC-CSS1#length-units :
     "Absolute length units are only useful when the physical properties of
      the output medium are known."