Web Typography Tutorial – Lesson 2

By | September 14, 2015

Ask any web designer about the use of typographic design on web pages and they’ll tell you the same truth: The web is a harsh, uninviting environment for the delicateness of fine typography. Along with the usual web culprit of platform inconsistency, the extreme low resolution of even the best current screens means type online can only allude to the geometry of the typefaces you’ve so carefully chosen and specified.

The Devil’s in the Display

The fundamental problem of online type has nothing at all to do with the Web. The problem — whether you’re building pages for a website, CD-ROM, Palm Pilot, cell phone, or museum kiosk — is the display. On a computer screen, at least at relatively small sizes, Helvetica is not Helvetica. The chunky pixels on a 72- or 96-pixel-per-inch screen can’t possibly match the subtle curves of type.


This means that for body copy, we can barely produce legible type, let alone make subtle stylistic distinctions. What we’re left with is the grossest conceivable control – straight versus slanted, static versus dynamic, old versus new, light versus heavy, serif versus sans-serif. While it will take radically-better displays to bring onscreen typography up to the standards of the ancient Romans, there are several techniques which do help somewhat.


  1. Pushing Pixels
  2. HTML and CSS
  3. When is a Point Not a Point?
  4. GIF Images
  5. Flash
  6. Trouble in Paradise
  7. SVG
  8. Acrobat
  9. Resources On the Web and In Print
  10. Suggested readings


Pushing Pixels


The problem of translating curves to pixels can be mitigated in larger (i.e., display) sizes by a technique called anti-aliasing. Anti-aliasing is the process of tricking the eye into seeing smooth curves instead of jagged pixels by using colored pixels around the edges of letterforms. Because the pixels are intermediate in tone and color between the type color and background color, they have the effect of smoothing out the curves.


The two problems with anti-aliased text are:

  1. it looks fuzzy, and
  2. it only works with relatively large sizes of type.

When used with body sizes, anti-aliasing often only produces a mushy mess. An interesting secondary consideration for the Web is that anti-aliased text may appear more corporate or polished and less “immediate” than straight HTML text.


At small sizes, there’s only so much that can be done to improve on-screen legibility and fidelity to the “real” typeface, and it’s done with a technique called “hinting.” Hinting is a method of tweaking the outlines of letterforms so that they match up as well as possible to the screen’s pixels in order to produce the closest possible – or at least less mangled – reproduction of those ideal outlines. Hinting information is included as part of a typeface, so it’s not something you’ll need to do yourself, but if you’re interested in the gory details, take a look at this Microsoft article on hinting in TrueType.

While the practice may be esoteric, the results of good hinting can be quite dramatic. Compare, for example, the following samples of the same text (more or less) set in the meticulously hinted Verdana as compared with Helvetica.


Now you know why the vast majority of commercial Web pages created in the last year use Verdana. (There’s a second, related, reason:Verdana, designed by Matthew Carter and hinted by Thomas Rickner, was originally designed as pixel-friendly bitmaps. Once those were just right, Carter made outlines from the bitmaps instead of the more-common practice of designing outlines and then trying to generate bitmaps. Another screen-friendly face is Georgia, designed and hinted by the same team.)


Another option, especially for really tiny sizes is to use bitmapped typefaces. Since they’re designed specifically as bitmaps, without curves at all, faces like Silkscreen and Mini7 don’t have the same problem traditional outline fonts have onscreen. On the other hand, because they’re designed to the pixel, they work only at the specific sizes for which they were designed. Still, an entire visual style has arisen from these tiny pixellated fonts.



Even if display resolution wasn’t an issue, type online faces a second major problem:the familiar bugaboo of platform inconsistency. This takes several forms, including different browser and plugin capabilities and – most challenging – different installed typefaces. We’ll take a closer look at these issues as we discuss the various technologies for specifying type on the Web:HTML/CSS, GIF images, Flash, SVG, and Acrobat.



The current XHTML spec provides rudimentary font control with the FONT tag, which allows page authors to specify typeface and rough size, like so:

1 <font face="Verdana" size="3">

However, this technique, while widely practiced now, is currently being phased out in favor of Cascading Stylesheets. CSS provides significantly more control, which we’ll explore in depth a little later. However, as giving and wonderful as they are, even HTML and CSS have several problems in common. Perhaps the biggest headache arises from the fact that people viewing our meticulously crafted pages may be seeing them in a totally different font than we intended because not everybody has the same typefaces installed on their machines.


But, you protest, we can just embed the fonts. And we certainly can, and probably should, but we will still have to assume that a significant portion of our audience won’t ever see them. Probably the two biggest reasons more people don’t embed fonts are that the tools have really confusing interfaces, and we still have to design around the possibility the fonts won’t be downloaded. This paragraph, for example, is set to be displayed in Gill Sans and I’ve embedded the font, but many of you will see it in the default font for this page instead (which probably looks a lot better in this case). For the full scoop on font embedding, check out Mulder’s excellent tutorial.

The Shotgun Approach

If we can’t fully rely on embedded fonts, we’re stuck with guessing what our viewers might have installed. Luckily, we have a few techniques to help us. First off, the HTML FONT tag and CSS font-family property allow us to specify a list of faces, such as “Verdana, Arial, Helvetica”. The browser will display the first typeface in the list which is available.

Next, we can make educated guesses based on default Windows and Macintosh fonts and the fonts installed by recent versions of Web browsers. Microsoft has a page listing some commonly installed fonts (and not only Microsoft ones). The default fonts are so limited, in fact, that we see the same strings over and over on Web pages:”Verdana, Arial, Helvetica”, “Georgia, Times New Roman, Times”, “Courier New, Courier”.

Commonly-installed typefaces on Macs and PCs

Windows MacOS
Serif Georgia

1 MS Serif
3 Book Antiqua
5 Times New Roman

1 New York
3 Palatino
5 Times
Sans-serif Verdana

1 MS Sans Serif
3 Arial
5 Trebuchet

1 Geneva
3 Helvetica
5 Chicago
Monospace Courier New Courier
*Georgia and Verdana are installed on Macs by MSIE, so they may or may not be present.

Generic Families

Finally, we can use generic family names – ‘serif’, ‘sans-serif’, ‘monospace’, ‘cursive’, and ‘fantasy’ – to tell the browser to use the closest available face. (I have to take issue here with the absurd notion that “fantasy” should be one of these five core generic families – that one must have been added during some after-hours partying over at the W3C.) Finally, keep in mind that, as put in the CSS 2 spec, “Generic font families are a fallback mechanism, a means of preserving some of the style sheet author’s intent in the worst case when none of the specified fonts can be selected.”

“Verdana, Arial, Whatever”

So, if you want a sans-serif face, you just plop in “Verdana, Arial, Helvetica, sans-serif” and you’re good to go. If people look at your site and don’t have Verdana installed, they get Arial or some other sans-serif face and we can all move on to reading your brilliant article about collecting toy robots. Right? Well, yes and no. The mechanism works fine, but shoot – if all sans-serif faces looked the same, there would be no point to my writing the whole first part of this article. A second issue – especially important for body type – is that, as we’ve learned, different typefaces at the same point (or pixel) size can appear to be quite different sizes. Indeed, the CSS 2 spec addresses this problem with the font-size-adjust property and also includes a detailed algorithm for more specific font-matching, so we’ll still have degradeability but with at least some more control over the actual shape of the letters rather than their membership in hopelessly broad families like “sans-serif” and “serif.”

As a side note, there is a particularly funky hack for detecting installed fonts. It involves using JavaScript to compare the relative sizes of a layer of text set in the default face with one set in the face you’re testing for. It’s fairly ugly, but works surprisingly well. Unfortunately, there’s not all that much you can do with that information once you have it.


When is a Point Not a Point?

Type is traditionally (i.e., in the print world) measured in a unit called a “point,” which is 1/72nd of an inch on paper. But screens are based on pixels, rather than points. On the original Macintosh, there were close to 72 pixels per inch on the screen, so points and pixels matched up quite nicely, thank you. But now, displays and resolutions vary widely and Macs and Windows machines make significantly different guesses about them. Without getting into the gory details, type specified in points (or any point-based measurement) will appear larger on a Windows machine than on a Mac.

One solution is to conditionalize your type sizes for different platforms if using CSS or HTML. Another is to use the CSS “px” (for pixels) unit, which will force everything to the pixel grid. The primary drawback is that text set in pixels will generally foil user-defined text sizes. This can cause usability problems, especially if you’ve chosen particularly small sizes. It also may cause printing trouble (if the printer tries to translate your pixel sizes into points – more on CSS and printing in a moment). But for now, the alternatives may be worse.

In HTML, all we can specify is family and a rough measure of size. With CSS, however, not only can we specify exact size increments, but we can control such crucial properties as line-height, word-spacing, and letter-spacing (for more on using these properties, see lesson 3 on word- and letter-spacing and line-height). Line-height alone goes a long, long way to improving the readibility of a Web page.

Another advantage of CSS is the ability to specify different stylesheets for different output devices. The most obvious example is to include a separate stylesheet for printing a page (specifying different typefaces, perhaps, or using points rather than pixels for sizing), like so:

01 <style type="text/css" media="print">
03 .someClassName { font-family:Bodoni, Georgia, serif; font-size:10pt }
05 </style>
09 <style type="text/css" media="screen">
13 .someClassName { font-family:Georgia, serif; font-size:12px }
15 </style>

or, linked, like so:

1 <link rel="stylesheet" type="text/css" media="screen" href="screen.css" />
3 <link rel="stylesheet" type="text/css" media="print" href="print.css" />

Finally, I wanted to point out what I see as a big problem with using CSS/HTML for specifying type:Designers still lack control over anti-aliasing, especially in display type. Depending on your visitor’s particular operating system and settings, type will either be anti-aliased or not. You, as a designer, have no control, which is a darn shame because, as you now know, anti-aliasing doesn’t make sense for all typefaces at all sizes.


GIF Images

You may think that the lack of control over the way type displays on screen is no big deal. You can just make all your type out of images – GIFs or JPEGs – right? Well, yes and no. Using images to specify type looks at least as good as anything else onscreen and can be seen by almost all browsers, but it also introduces a number of serious problems.

The first problem is that images take up more file size than plain text, which can lead to slower display of your page. Related to this is the issue that each image (and a single page can have many if each header or navigation element is treated as an image) will require a separate server connection, again slowing down the time it takes for your page to display.

Besides speed issues, text in images isn’t selectable or copyable. And it’s not viewable by text browsers such as Lynx or screen readers for blind Web surfers. The workaround is to religiously use the ALT attribute of the <img> tag, which you should absolutely do. (If you’re not sure what to write, there are plenty of detailed ALT text guidelines on the Web.) Finally, text in images is fixed in size, which means it cannot scale along with non-image text on your page.

In addition to its considerable, though not insurmountable, usability problems, image text can be a pain to manage. Changing text contained in an image requires an image-editing program and the ability to use it, often the organizational province of a graphic designer, while plain text can easily be changed by a copyeditor or other member of a Web production team. Similarly, a change in visual treatment requires changing all images on a site. This is especially significant on a large site where a single change may occur across many images. By contrast, CSS-styled text can be changed simply by editing the appropriate style rule. Finally, text in images is not so easy to generate dynamically (although it certainly can be done). The bottom line is that images are not generally appropriate for personalized portions of a site.

Where images do make sense for text is in navigation or title treatments, where carefully specified and anti-aliased display type can make a site feel much more polished and expressive than jagged default HTML type. Just make sure not to forget about ALT text and consider using plain text if you have a large number of items, such as the navigation on a large news site like CNN.



The reason images are so wasteful of bandwidth is that they’re based on pixels rather than a more efficient method of describing visual information, such as [[Reference:Vectors | vectors]. So it stands to reason that a vector-based way of rendering type might make more sense for the Web. The most obvious current choice is Macromedia’s Flash.

In terms of type, Flash offers several advantages. The first is file size, as you can see in the following example:

Flash:548 bytes


Gif:1,459 bytes

As you can see (assuming, that is, you have the Flash plug-in, which we’ll discuss later), the GIF is almost three times as large as the Flash version. Since Flash is all based on vectors, in fact, the larger the type, the bigger the file-size savings. Double the size of the type, and the Flash file will still be only 548 bytes. The second advantage (as you can see above) is selectability. You should be able to select the text in the Flash example and then copy and paste it. Finally, Flash text can be pulled from an external source – an XML file or a Web server for example – which means both that content management is less a problem than with image files and that text in Flash can be dynamically generated, which as I’ve mentioned is relatively difficult using an image.

For static text in Flash, there’s no need to embed the font as it will be saved as outlines. For dynamically updated text, Flash supports embedding of fonts, either an entire font or specific glyphs. As with CSS font embedding, the font data can be saved as a separate file and linked from multiple Flash movies. It’s also possible to tell Flash to handle type similarly to how HTML and CSS do, by using “device fonts,” although you’ll be limited to the generic groups (‘_serif’,’_sans’, and ‘_typewriter’). And don’t forget, with Flash, you can make your type dance and twirl and fade in and out. I’m not saying you should, just that you can.


Trouble in Paradise

But Flash has problems of its own. One of the big ones has to do with anti-aliasing. The trouble is that Flash has no ability to selectively turn anti-aliasing on and off. Either everything in the movie is anti-aliased or nothing is. It sure would be nice to be able to use, say, 10pt Georgia for big blocks of text with no anti-aliasing and still have nice anti-aliased 36pt titles. Are you listening, Macromedia?

Another significant problem is that Flash files included on your pages won’t get printed along with the rest of the page. Flash has an internal print mechanism, so you can add a print button to a standalone Flash site, but that won’t help with Flash embedded along with HTML in a Web page. If you print this article, for example, you’ll see only empty boxes where the Flash samples should be.

Then, of course, there’s the fact that Flash is a plug-in rather than a “native” Web language like HTML. This is a legitimate concern, but at this point, after years of browser manufacturers forcing proprietary capabilities on us while ignoring established specifications (like CSS), I’m not sure what’s so “native” about HTML and CSS. And Flash is quite widely distributed, with Macromedia claiming over 90 percent “penetration” worldwide. Still, not everyone who visits your site will have the plugin, let alone the latest version. So you’ll want to consider whether you need to have a separate version of your site for non-Flash users. Recent versions make this more feasible by allowing you to store content as XML, readable by Flash and relatively easily convertible to HTML for accessibility.

Finally, many people have pointed out glaring usability problems in Flash movies, often attributing the lack of usability to Flash itself. It’s important to understand that many of the common problems (such as long intro animations, obfuscated navigation, and frustrating, non-standard scrolling mechanisms) are due to poor design rather than some inherent aspect of the authoring tool. On the other hand, Flash does have some definite problems, such as its inability to respond to the browser’s back button or to allow the user to bookmark a specific “page” in a Flash movie. Many of these issues can be overcome with good interaction design – the back button is less of a worry, for example, if you don’t force your visitors into a navigational dead-end – but they may require extra attention. For more on Flash usability, take a look at Macromedia’s Flash accessibility pages or Flazoom’s usability section.

If you’re new to Flash and want to learn how to use the darn thing, visit the Flash Tutorial for Beginners. For more on pixels and vector graphics, take a look at Web Graphics for Beginners.



SVG, like Flash, is a format for describing vectors. In fact, you can think of SVG as a sort of W3C-sanctioned version of Flash, although there are some important differences, most notably that SVG data exists as plain text, rather than in a binary format as does Flash, and that that text is formatted as XML. In fact, once you get past all the contextual stuff like document type declarations and so on, SVG is a pretty straightforward way of describing shapes:

01 <rect
03 x="100" y="100"
05 width="400" height="50"
07 fill="#33cc33"
09 stroke="#000000" stroke-width="2"
11 />

Much of the promise of SVG lies, in fact, in its promise. As it exists today, it can only be viewed by people who have installed the Adobe plugin. OK, there are lots of SVG viewers out there, but I’m talking about regular people, not geeks who install development applications. But the idea of being able to handle vector graphics side-by-side with HTML and XML is quite powerful. For animations, it remains to be seen if SVG can compete with Flash, but for static type, SVG could be a godsend. SVG, like Flash, includes several methods for embedding typefaces.

I want to point out something here:Flash is a relatively mature authoring environment which happens to output movies in a particular binary format. As such, it has a great advantage over SVG, no matter the benefits of SVG’s strict XML format. Right now, this is probably the most important distinction – aside from plug-in distribution – between the two. This doesn’t mean that SVG won’t have its own authoring tools – it will. Indeed, Illlustrator 9 already supports SVG and LiveMotion eventually will as well. Or, just as likely, we’ll soon use Flash to generate SVG.

There’s growing support for SVG on the viewing side, including both Web browsers and mobile devices. It seems fairly safe to say that either SVG will be a usable part of our lives relatively soon or, if not, that Flash and SVG will converge enough to make the distinction moot.



And then there’s Acrobat, an entirely different animal. Instead of operating within a Web page, Acrobat files operate in their own self-contained universe. This means on one hand that you’d never use Acrobat to make page titles for a Web page. On the other hand, Acrobat promises precise control over the design of a page. The key word here is “page.” Think of Acrobat as an excellent way of distributing paper-like pages over the Internet.

Acrobat files will print exactly as authored, so they can be great for publishing reports or other documents that require graphic and typographic precision. On-screen, however, they’re more than a bit clunky to navigate, often seeming either a bit too large or a bit too small for comfortable reading. Accessibility can also be a problem, although Adobe has done quite a bit to address this with the latest release (Acrobat 5) and by providing tools like their Acrobat to HTML converter. Like Flash, Acrobat requires a browser plugin.

Finally, despite free and paid converters online, you’ll likely want to invest in the full version of Acrobat for satisfactory control over your output.


Resources On the Web and In Print

Whew! For a brief introduction to typography online, that’s a whole lot to digest. But now you hopefully know enough to choose and set type with confidence, and you can work around some of the problems of using type online. If you want to learn even more, I encourage you to explore the following resources I’ve included below.

Selected resources

Type foundries

  • MyFonts.com (MyFonts.com is a Reseller of typefaces for many different foundries.)
  • Adobe
  • AGFA-Monotype
  • Bitstream
  • Emigre
  • FontBureau
  • FontShop
  • House Industries
  • ITC (International Typeface Corporation)
  • Linotype Library
  • P22
  • Storm
  • T-26
  • Free fonts:there are loads of sites offering free fonts for download. Many of them are quite nice, but many more are relatively shoddy, either in design or in quality. In general, you’re best off buying a small number of high-quality fonts from a reputable source. This may also encourage you to use fonts to support text rather than the other way around. As [/webmonkey/html/96/46/index2a.html Kristin wrote] way back in ’96, when it comes to type, “Simple is almost always best.”


  • Typographic Design:Form and Communication
  • The Elements of Typographic Style
  • Stop Stealing Sheep & Find Out How Type Works
  • A History of Graphic Design
  • The End of Print
  • Typography
  • FontShop FontBook
  • Precision Type Font Reference Guide

Magazines and other typography resource sites

  • Web Page Design for Designers
  • Microsoft Typography
  • U&lc:Upper & lowercase Magazine
  • FUSE
  • Createivepro – fonts
  • Robin Williams’ Type Talk
  • Fontsite
  • Type books
  • x-height
  • Lines & Splines
  • Textism
  • Typographer.com

A hopelessly incomplete list of type designers worth knowing

  • Aldus Manutius
  • Francesco Griffo
  • Claude Garamond
  • William Caslon
  • John Baskerville
  • Giambattista Bodoni
  • Morris Fuller Benton
  • Frederic Goudy
  • Eric Gill
  • Jan Tschichold
  • Paul Renner
  • Hermann Zapf
  • Adrian Frutiger
  • Paul Rand
  • Herb Lubalin
  • Saul Bass
  • Erik Spiekermann
  • Susan Kare
  • Neville Brody
  • Matthew Carter

I encourage you to take some time and browse these resources. Pick up a book or two on type. Find a few designers whose work is appealing to you, and then check out their friends. But just remember, the best way to learn about type — or anything else in design for that matter — is by experimenting. So, after reading up and looking around for inspiration, pull out your sketch book or start up your favorite graphics program and do some sketches. And when you think you’re done, do some more. And before you know it, you’ll be a typography pro!


Leave a Reply

Your email address will not be published. Required fields are marked *