Toward a standard font size interval system

Todd Fahrner, Verso

This document is under construction, so you'll encounter a few "staircases into air," non-sequiturs, etc. Bear with me. If you're really keen on this stuff, and can't wait for me to get it together here, you might do an advanced search at Deja for "fahrner pixel" and review the threads turned up from the "mozilla" newsgroups.

Note: This document contains exhibits that are styled extensively with Cascading Style Sheets (CSS1). These exhibits are known not to display with a useful degree of accuracy in any released version of Netscape Navigator/Communicator. I have certified adequate accuracy only in recent versions of MS Internet Explorer. If in doubt, please visit with Explorer.

  1. Abstract
  2. The problem
  3. The solution
  4. Trouble in paradise: the CSS keywords
  5. Building a better scale
  6. Synoptic table
  7. A mathematical excursus
  8. Implementation implications
  9. User interface assumptions

Abstract

This document discusses the strengths and weaknesses of various deployed and recommended methods of specifying font sizes in Web documents and application interfaces, and proposes a harmonization. This scheme will enhance the legibility, clarity, and aesthetics of documents presented on screen, and help retire less elegant alternatives that are hurtful to the Web as a dynamic information resource - one that is accessible to users with widely varying needs and purposes. It is intended for Web browser and stylesheet implementors of all religions, but may be of interest to Web authors and digital typography and/or CSS enthusiasts at large.

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 font size ranges distinctly and attractively at low screen resolutions. Part of the difficulty stems from the variable design and quality of fonts themselves, for which a partial solution has already been recommended. This piece addresses a more elementary problem: the need for (and lack of) a standard font size interval system.

"Two steps smaller" or "extra large" have no normative default meanings across applications or platforms (i.e., on the World Wide Web). This means that when designers avail themselves of such expressions, the results are often unexpectedly crude or illegible. Desperate or naive designers usually seek relief in inflexible pixel or print-specific absolute units such as points instead. The worst case is common practice: the designer simply turns most or all text into graphics.

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. Ironically, as the powerful, ill-implemented, ill-understood Web typography language CSS begins to see wider use, the problems grow more acute. Even when legibility per se is not impaired, arbitrary or ill-conceived font size interval differences often interfere unacceptably with the accessibility, logical clarity, or aesthetics of documents. Standard scaling behavior can foster effective, portable, low-resolution typography as fundamentally as the 12-step division of the octave has fostered Western tonal music.

Specifics

Users require or prefer different base font sizes on screen depending on the font design, their eyesight, 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 relative "em" or percentage lengths rather than absolute lengths such as "pt" or "cm".

There's a big problem with this recommendation, however: specifying font sizes in any length unit - relative or absolute - presents serious usability hazards.

What's wrong with specifying font size in relative length units

It is indeed more appropriate to specify font sizes for screen display in relative length units than in, say, points[1]. Common browser bugs aside, specifying larger sizes in relative length units through CSS is seldom especially 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.

For instance, Web browsers for the MacOS have historically defaulted to displaying "medium" text at 12 pixels per em (12pt @ 72ppi fixed logical resolution). Upper- and lower-case characters in the roman alphabet cannot be represented with fewer than 9 pixels per em. Therefore, all font sizes below "75%" are illegible in current MacOS browsers unless the user has expressly chosen a larger value for "medium" than the 12pt default. (Sizes below 9pt, often specified as such by users of MS Windows-based authoring products, are irrecoverably illegible in today's Mac browsers as long as CSS is enabled.) The problem is so severe that developmental versions of the "Mozilla" browser for MacOS even deployed a "font size hack" for a time that forced all text to display at at least 9pt. This eliminated any apparent font size changes below a certain threshold: information loss. The "solution" was to change the Mac browser's default resolution to 96ppi, to match that of dominant Wintel PCs. The result: a bigger default value for "medium".

It remains to be seen how Mac users will react to seeing "12pt" text render at 16 pixels in Netscape 5.0 while earlier versions (and all other Mac applications) render it into 12. Undoubtedly, many will set it back to what they're used to, and with good sense: smaller (legible) text means more information on screen - less scrolling, more and smaller windows, higher productivity. A small base value for "medium" is thus not simply a Mac user support issue; it is a support issue for any user who wishes to maximize the information density of his or her display, or for any who may simply prefer the look of fonts smaller than 16px on screen. Obviously, such concerns will drive configuration choices for portable Web devices, whether they are running Windows CE or something else. As long as this is the case, specifying smaller-than-medium text size in relative length units through CSS will be problematic.

The proper use of relative length units can be deceptively difficult when document elements are nested. For example, if list items are styled through CSS to be at "80%" size:

li { font-size: 80% }

... all may appear to be well until lists are nested. Since relative length units refer to the size of the parent element, the size of the nested elements should then be the compound: 64%. Consider the case of nested divisions:

This is a given size of "medium" text.
This is div 1
This is div 2, in div 1
This is div 3, in div 2

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: 100% }

The complication of such an approach is discouraging, especially to novices. The problem might also be circumvented by using class or id instead of an element selectors, but this assumes that the stylesheet author is free to modify or has even ever read the document: an increasingly invalid assumption given the economy of generic stylesheets, and the growing respect for documents as data, as evident in the rise of XML.

Finally, even contextual and/or class selectors fail spectacularly in the face of a deeply entrenched bug: selective inheritance of font style into tables. Resetting a mysterious set of style properties to their defaults when the document parse tree happens to branch into tabular elements is a plain violation of the CSS specification, yet both Netscape and Microsoft's current browsers for Windows exhibit this quirk. Deployed in haste by Netscape in 1995 with its introduction of the FONT and TABLE elements, painstakingly copied by Microsoft shortly thereafter, and now corrected by Opera and Microsoft's own Internet Explorer team for MacOS, this bug is defended to this day as a "feature" by the Internet Explorer team for Windows. It is beyond the scope of this piece to plumb this entomological pathology in depth, but a live demonstration [link] should suffice.

The solution

The solution is for the designer to specify sizes not in any length system - relative or absolute - but in literals (keywords) whose actual values adapt intelligently to the baseline or "medium" value chosen by the user. Such "absolute size" schemes have the unique benefit of being both based on a user-chosen size and "node agnostic;" i.e., the document structure does not complicate the meaning of absolute sizes the way it complicates the meaning of, say, "75%". Furthermore, the actual values of literals can vary in more sophisticated ways than simple relative length units, taking font quality and available resolution into account.

Neither the problem nor the solution are new: Netscape included it in its original implementation of size attributes on the now-deprecated FONT element, and the HTML heading sizes 1-6 have adapted to the user's base size since Mosaic. The scaling interval between steps in this system varies nonlinearly along the scale, depending on the pixels-per-em value of the baseline value chosen in the user preferences:

16ppem - 12pt@96ppi
(Windows UA default)

1-3 interval: 60%

16ppem - 12pt@96ppi (Windows UA default)
12ppem - 12pt@72ppi
(legacy MacOS UA default)

1-3 interval: 75%

12ppem - MacOS default
live

1-3 interval: varies with pixels-per-em
of your choice of "3" (user's default)

Font size=7
Font size=6
Font size=5
Font size=4
Font size=3
Font size=2
Font size=1

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.

This obscure, sophisticated behavior supports not only the usability of the FONT tag's size attribute, but also governs the sizes of headings H1-H6, as well as the BIG and SMALL elements. Valuable and ill-documented, it is in danger of being left behind in the transition to CSS.

Trouble in paradise: the CSS keywords

CSS putatively supersedes the HTML font sizes with absolute size keywords of its own: xx-small, x-small, small, medium, large, x-large, and 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 advisable:

CSS absolute size keywords: xx-small x-small small medium large x-large xx-large
HTML absolute font sizes: 1 2 3 4 5 6 7

Note that in the CSS scale, "medium" is in the middle, while the HTML size scale (with "3" as the axis) is asymmetric. The CSS scale has three rather than two steps below medium. Sadly, Internet Explorer 5.0 for Windows has implemented the CSS keywords exactly as above, leading to the absurdity that font size "medium" means "one size bigger" when used in an author stylesheet, while "small" corresponds to the "medium" entry in the user stylesheet (i.e., when "medium" is selected through the font-size UI element).

To preserve the natural correlation of CSS's "medium" with HTML's "3", and avoid extending the scale below the current barely-legible "1" value, a step must be interposed between sizes 1 and 3:

CSS absolute size keywords: xx-small x-small small medium large x-large xx-large  
HTML absolute font sizes: 1   2 3 4 5 6 7

Obviously, the algorithm or dataset that produced the distinct and legible display of two sizes below a variable size 3 is no longer suited to this CSS-harmonized scale. Implementing the CSS scale in a usable manner while maintaining consistency with the earlier model is an important problem.

The CSS specifications don't spell out the solution; in fact, they suggest poor ones. CSS-1 suggested a disastrously high 1.5 scaling interval between indices. Netscape 4.x implements this, making the keywords unusable in practice (illegible indices flagged in red):

CSS absolute size keywords: xx-small x-small small medium large x-large xx-large
px computed from a 16 ppem base:

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


CSS1 suggested 1.5
scaling factor between indices
5px

Épe
Épe
Épe
Épe

7px

Épe
Épe
Épe
Épe

11px

Épe
Épe
Épe
Épe

16px

Épe
Épe
Épe
Épe

24px

Épe
Épe
Épe
Épe

36px

Épe
Épe
Épe
Épe

54px

Épe
Épe
Épe
Épe

px computed from a 12 ppem base:

e.g., 12pt @ 72ppi or 9pt @ 96ppi
(legacy Mac OS UA default)


CSS1 suggested 1.5
scaling factor between indices
4px

Épe
Épe
Épe
Épe

5px

Épe
Épe
Épe
Épe

8px

Épe
Épe
Épe
Épe

12px

Épe
Épe
Épe
Épe

18px

Épe
Épe
Épe
Épe

27px

Épe
Épe
Épe
Épe

41px

Épe
Épe
Épe
Épe

CSS-2 amends CSS-1 to suggest a 1.2 scaling factor, but this factor still produces illegible results for either x-small and/or xx-small when medium has any ppem value lower than 15:

CSS absolute size keywords: xx-small x-small small medium large x-large xx-large
px computed from a 16 ppem base:

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


CSS2 suggested 1.2
scaling factor between indices
9px

Épe
Épe
Épe
Épe

11px

Épe
Épe
Épe
Épe

13px

Épe
Épe
Épe
Épe

16px

Épe
Épe
Épe
Épe

19px

Épe
Épe
Épe
Épe

23px

Épe
Épe
Épe
Épe

28px

Épe
Épe
Épe
Épe

px computed from a 14 ppem base:

e.g., 12pt @ 84ppi or 14pt @ 72ppi -
higher than either the Mac UA default
or X-Windows' "75ppi" bitmap fonts


CSS2 suggested 1.2
scaling factor between indices
8px

Épe
Épe
Épe
Épe

10px

Épe
Épe
Épe
Épe

12px

Épe
Épe
Épe
Épe

14px

Épe
Épe
Épe
Épe

17px

Épe
Épe
Épe
Épe

20px

Épe
Épe
Épe
Épe

24px

Épe
Épe
Épe
Épe

px computed from a 12 ppem base:

e.g., 12pt @ 72ppi or 9pt @ 96ppi
(legacy Mac OS UA default)


CSS2 suggested 1.2
scaling factor between indices
7px

Épe
Épe
Épe
Épe

8px

Épe
Épe
Épe
Épe

10px

Épe
Épe
Épe
Épe

12px

Épe
Épe
Épe
Épe

14px

Épe
Épe
Épe
Épe

17px

Épe
Épe
Épe
Épe

21px

Épe
Épe
Épe
Épe

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). The more likely corollary is that conscientious designers will continue to use HTML's FONT, BIG, and SMALL tags for font size modulation until CSS's font size intervals are harmonized with the more sophisticated legacy system and broadly implemented.

Building a better scale

[construct a harmonized scale that does the job - or just jump ahead to the "synoptic table" if you can do without the drama]

Increments and decrements

[discuss how to handle relative values ("larger", "-2") along the not-quite unified font size and CSS keyword scales]

Synoptic table

[ provide textual explanation ]

 

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  
normalized scaling factor: 60% - 3:5 75% - 3:4 89% - 8:9 100% - 1:1 120% - 6:5 150% - 3:2 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

24px

Épe
Épe
Épe
Épe

30px

É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

19px

Épe
Épe
Épe
Épe

24px

É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

18px

Épe
Épe
Épe
Épe

23px

É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

17px

Épe
Épe
Épe
Épe

21px

É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

16px

Épe
Épe
Épe
Épe

20px

É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

14px

Épe
Épe
Épe
Épe

18px

Épe
Épe
Épe
Épe

24px

Épe
Épe
Épe
Épe

36px

Ép
Ép
Ép
Ép

note: values in graphic are out-of-date.

Pixel values of CSS absolute size keywords

A mathematical excursus

[discuss the physical origin, precedents, and musical correlations of the proposed scale]

Implementation implications

[spell it out]

The user picks a preferred length value in prefs. You figure out the pixels-per-em (based on the logical res if an absolute length such as a "point" size). Then you calculate the values of the keyword sizes according to the scaling factors given in the "synoptic table" above. If the user changes the font size via a "topside" (non-prefs-based, transient) affordance, you traverse the keyword size scale.

Implementing the current proposal should make it possible to add the following to the browser default stylesheet, and then forget about HTML font size issues everywhere else:

small {
 font-size: smaller;
 }
big {
 font-size: larger;
 }
h1 {
 font-size: xx-large;
 }
h2 {
 font-size: x-large;
 }
h3 {
 font-size: large;
 }
h4 {
 font-size: medium;
 }
h5 {
 font-size: small;
 }
h6 {
 font-size: xx-small;
 }
font[size=1] {
 font-size: xx-small;
 }
font[size=2] {
 font-size: small;
 }
font[size=3] {
 font-size: medium;
 }
font[size=4] {
 font-size: large;
 }
font[size=5] {
 font-size: x-large;
 }
font[size=6] {
 font-size: xx-large;
 }
font[size=7] {
 font-size: 300%;
 }
font[size=-1] {
 font-size: smaller;
 }
font[size=+1] {
 font-size: larger;
 }
font[size=-2] {
 font-size: 60%;
 }
font[size=+2] {
 font-size: 150%;
 }
font[size=+4] {
 font-size: 300%;
 }
 

User interface assumptions

[discuss conceptual model of what all this means to the user, and current UI perversities such as IE having users define the value of "medium" as "medium" "larger" "smallest" etc. instead of something like a point or pixel value. ]

In prefs, users must be able to define the length-unit value of the "medium" keyword. All the rest of the keyword length values would be calculated based on the ppem of the user choice.

There may be additional, auxilliary UI to adjust font sizes on a page-by-page, domain-by-domain, or session-by-session basis (unlike prefs, which persist across sessions). Choices may be keywords, relative or absolute.



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."