Re: Best practice for font control

At 01:40p -0800 01/21/00, Todd Fahrner wrote:
>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 guess I'll chime in here too.

>    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

True; we just lack the vocabulary to condense those sentences into two words.

>    All of this goes out the window when typical screen resolutions 
>exceed ~150ppi and/or universal anti-aliasing becomes a matter of 
>course.

Anti-aliasing looks terrible at small font sizes on 72ppi (one of the 
reasons people hate reading documentation in Acrobat), so let's leave 
out the and/or. ;)
Hmm... I wonder when Mitsubishi will have a 144ppi NF display, and 
when it will be as *affordable* as today's displays. 20 years? In 
Internet time, that's like another millenium. For now it's still a 
pie-in-the-sky concept (maybe Bill Gates and Steve Jobs can afford 
one, but most people can't).

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

I think there are just 2 cases where specifying a font by pixels is 
warranted: 1)to geometrically match a font to an adjacent bitmap 
picture, or 2)to prevent the illegible Arial-9-viewed-on-Mac 
situation.

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

I haven't seen the 96dpi-on-72dpi Tasman thing yet, but I imagine it 
will be horrid. If my math is right, a CSS-specified font of Geneva 9 
would appear on IE5's 96dpi scaling as Geneva 12. Blech. Geneva 12 is 
uuuugggllllyyyy. If I specify Geneva 9, it's because I know it looks 
pretty. If I wanted a font as huge as Geneva 12, I'd spec Helvetica 
instead.

Tantek? Is there a way to preserve Geneva 9's "pixel density" when 
the user has specified the 96dpi scaling, or must I resort to 
specifying in px?


-Walter

Received on Wednesday, 2 February 2000 03:13:41 UTC