Users: Answering to the Audience
Users and Font Choice
Few Web developers may be aware that the fonts they work with daily - Times Roman, Arial, and Helvetica, among others - were not designed to be easily read on a screen. These fonts were for the high-resolution printed page. They can scale poorly and become unreadable at small sizes on a low-resolution computer monitor (Gillespie, 2001).
The first platform to possess fonts designed especially for the screen was Macintosh. Fonts such as Geneva, Chicago, Monaco, and Espy Sans were created to scale well and look smooth along the edges. Screen fonts for Windows followed much later, but Verdana and Georgia are now acceptable Web fonts and have been made widely available by their inclusion with Internet Explorer (Van Doren, 2001). Microsoft enabled the modification of Times Roman, a true printer font, into Times New Roman, a font that works equally well both on-screen and in print. Arial has undergone a similar process, but can still be unreadable at very small sizes (Byrne, 2004).
Developers may choose to design their pages with screen fonts, print fonts, or a combination of the two as previously shown in the font-family coding. This choice is important, because creating a style sheet that overrides the user’s preferences and only allows the use of one or two fonts guarantees that a percentage of the page’s audience will be locked out of its content. There is no guarantee that even a common font will be available to all users all the time. Shaw (2005) has created a chart to assist developers with translating their desired typeface across Windows, Macintosh, and Linux platforms. Results will not be exactly the same as the developer had envisioned, but will be more accessible to a wider audience.
Users and Font Size
Byrne points out that developers could have an easier time dealing with Web typography by not set any font size in a style sheet. Browser settings would take over and display the typography preferred by the user. He points out, though, that many users do not know that they can change their browser settings, and so would still not see the text that best meets their needs. He argues that developers who still want to control some aspects of a page’s typography need to give up the idea of absolute power and accept a degree of uncertainty in the final display of their designs (2005, section 1). Nowhere is this argument more cogent than in the area of font size.
As mentioned above in the section on coding for font size, print typographers use points to measure fonts, but the best CSS avoids absolute measurements. Instead, developers are encouraged to use relative measures such as px (pixels), em, and %. Why does it matter?
It turns out that there is a fundamental difference between the screen resolution of Windows and Macintosh machines. The Windows default resolution is 96 dpi (dots per inch), but the Macintosh default resolution is 72 dpi. A font cannot successfully form all its characters on a screen with fewer than 9 px. This works out to mean that no font is readable on a Mac below 8 points. It also means that, because Windows machines have more pixels per inch to work with, designers working with 10 point type in Windows do not realize that Mac users see something like 8.5 point type when attempting to read their pages (Byrne, 2005).
When a designer styles text with points, browser preferences cannot resize it. The user is stuck with tiny, unreadable text and an immense feeling of frustration. Even if the relative measurements used by CSS are less than ideal, they are an improvement over locking out a large portion of the Web-viewing public.
