Re: Best practice for font control

At 8:54 AM +0000 1/21/00, Bill dehOra wrote:

>A query on the best method to control fonts from CSS stylesheets arrived on
>another list which I'm subscribed to, CHI-Web, the ACM's usability mailing
>list. The query is from Don Norman: some of you may know him as a computer
>usability expert and author of 'The Psychology of Everything Things'. His
>company is trying to determine the best (or optimal) way to specify font
>sizes in their CSS, across browsers and platforms (should they use pt, px,
>em and so forth).

I'm sort of obsessed with such matters: it's my monster. Please 
excuse the freakish, choppy intensity this brings to my writing 
style. And thanks for the opportunity to exorcise so many vagaries at 
once.


All of CSS's text sizing systems are plagued with 
implementation-specific bugs, some more serious than others. These 
are too tedious to catalog here, but they drive a wedge into any 
discussion of "best practice" between the ideal and the pragmatic. 
Sadly, the two are often diametrically opposed. I fear that it will 
take several years of awareness building and standards advocacy[1] to 
bring the two into alignment.


My recommendations:


* Don't use points or other absolute length units for the screen media type.

This view is supported obliquely in the CSS specifications 
themselves[2], and explicitly in the Web Accessibility Initiative's 
authoring guidelines[3].
    The fallacy implicit in the use of points for a medium whose 
pixels remain individually perceptible is that the real physical size 
of characters, rather than the number and arrangement of pixels 
composing them, determines their legibility and aesthetic character.
    Four times out of five, I'll wager, when viewers complain that 
text on screen is "too small", what they really mean is that it is 
resolved into too few pixels. 8pt upper- and lower-case roman text at 
72dpi, for instance, is hopelessly illegible, even if "accurate" or 
magnified many times. See <http://style.metrius.com/junk/sizes.gif> - 
the third case. Real-world example: 
<http://style.metrius.com/font_size/points/font_wars.GIF>
    ACM's got labs, maybe? Here's an educated assertion in need of 
empirical testing: for running text, at arm's length, without 
anti-aliasing, at typical screen resolutions through the next several 
years at least (below ~150ppi), users will perceive a common 
rasterization of text at different physical sizes (+/-25%) as equally 
legible and aesthetically consistent, while they will perceive 
different rasterizations of the same text at a constant physical size 
as variably legible - sometimes illegible - and often not even 
apparently in the same typeface, depending on its hinting.
    All of this goes out the window when typical screen resolutions 
exceed ~150ppi and/or universal anti-aliasing becomes a matter of 
course.


* Avoid using pixels when practical.

Pixels are indeed the most appropriate unit to many WYSIWYG-addled 
authors' questionable objectives. They are the quanta that take over 
in usefulness from Newtonian absolute lengths on low-resolution 
screens, but pixels, like points, are not conversant with the 
user-chosen preferred font size. Their use is therefore objectionable 
on accessibility, general user-friendliness, and flexibility grounds.
    Note that the CSS specifications address the question of 
device-specificity by defining a pixel as a degree of visual angle 
(~0.0227), with a recommendation to scale pixels appropriately "if 
the pixel density of the output device is very different from that of 
a typical computer display", defined non-normatively as a 90dpi 
device. There are currently no implementations that scale pixels 
outside of a printing context, however, unless you count Opera's 
nifty zooming feature.
    The most recent developments on this front: both Mozilla (Netscape 
5, all platforms) and Internet Explorer 5.0 for MacOS (in 
development) will default to a 96dpi logical resolution, and a user 
default font size of 16 *pixels* (12pt@96ppi), laying the groundwork 
for an eventual reckoning of a pixel as .75pt for scaling purposes. 
[If your Web content includes scripts that depend naively on the old 
chestnut "PCs have bigger fonts than Macs", now would be a good time 
to retire or modify them.]


* Do use ems IF you are:

   * keenly aware of the parse tree of your markup, the
     genealogy of every node
   * committed to extensive cross-browser, x-version,
     x-user-config, and
     x-platform testing
   * prepared for late retreat or multiplication of effort
     in dubious workarounds.

Ems (and percentages) have the potential benefit of respecting the 
user-chosen font size, but are very difficult for many authors to 
master conceptually and practically, especially in view of many 
popular UAs' notoriously entrenched bugs concerning inheritance of 
font properties into tabular elements. The outlook for effective 
em/percentage support in popular Web authoring tools is not good IMO.


* Do agitate for consistent, thoughtful implementation of the 
absolute and relative size keywords.

Absolute and relative size keywords (xx-small - xx-large, 
larger/smaller, analogous to HTML's now deprecated 1-7 font sizes) 
represent potentially the most user-friendly and easy-to-author 
alternative, by a considerable margin. Unfortunately, they are also 
the most poorly implemented (and underspecified IMO), making them 
nearly useless for general WWW use, at least for the time being.


* Do preserve your sanity and use HTML's BIG and SMALL for font size 
modulation until the superior CSS alternatives are consistently 
implemented. Practical, robust, defeatist advice: 
<http://style.metrius.com/font_size/livetext.html>



Further reading:

* "Toward a Standard Font Size Interval System" - 
<http://style.metrius.com/font_size_intervals/altintervals.html> . In 
progress. Ponderous.

* <http://www.deja.com/home_ps.shtml> - search on "fahrner font" for 
endless elaboration.

* http://style.metrius.com/font_size/points/dump.html - a mess, some 
inaccuracies, but still generating favorable comment


References:

[1] e.g., <http://webstandards.org/css/>, 
<http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0372.html>

[2] <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." - i.e., not on the WWW's imponderable variety of 
screens.

[3] <http://www.w3.org/TR/WAI-WEBCONTENT/#tech-relative-units> - "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." Related site gag concerning the inadvisability of 
locking down a font size when you can't be certain of the font in 
use: <http://style.metrius.com/junk/wai.gif>

Received on Friday, 21 January 2000 16:40:41 UTC