The word
When the Internet first appeared, it was very much a text-only medium. Even the arrival of the Web didn’t change that immediately. Not until Netscape provided a browser which could display graphics was there any change in this. Even today, most web sites’ principal component is text. Text is almost always the medium used to get the message over — so it is important that it actually does that. Unfortunately, sometimes problems arise which get in the way. Let’s look at some of these.
Just like print?
A few years back it was pretty common to hear the claim that the printed text had been around since Gutenberg and we had learned quite a lot about presenting the printed word in those five or six hundred years. That’s undeniably true. What was more dubious was the implication — or even the explicit statement — that what was true for the printed word remained true for text displayed on a screen.
The Net being what it is, you can still find sites pushing this view. Some of the specific points made by its advocates are that paper is white, so Web pages should use plain white backgrounds; serif fonts are easier to read than sans-serif; text wider than 40–50 characters is difficult to read; and there is an established standard that new paragraphs begin on the next line with an indent — there is no extra white space between subsequent paragraphs.
All right, some of that is valid. Wide text is difficult to read. That is true on screen as well as on the page. It is also true that the standard HTML handling of <p> tags inserts an extra line of white space between paragraphs. This can make it difficult to differentiate a paragraph break from a section break within a body of text. The only workaround available in the past was to use <br> with either a series of non-break spaces or a transparent GIF. The latter is the technique advocated, for example, by David Siegel, one of the most articulate proponents of the print paradigm. (There’s more discussion of Siegel’s approach to web design in the article on alt text.) (There is, of course, a new solution — CSS — which is not yet fully supported. Support is, though, increasing; the technique is used on this site, so if you have a fairly standards-compliant browser, you will see paragraphs not separated by white space and with a 5% indent on the first line. This makes the code much more easily maintained and avoids the problems Siegel’s approach encounters when images are not displayed.)
Some of the other points, though, translate less well to the phosphor screen.
Serif or sans?
Serif fonts — such as this sentence, if your browser supports CSS — are generally accepted as being more readable than sans-serif fonts (which CSS-capable browsers should be using for the body text here). At least, that’s the case on the printed page. On-screen, this may well not be the case.
On a computer screen, serif fonts can look messy and be less easy to read than the clean lines of a sans-serif font. Some serif fonts can look a mess of black blobs on a screen, particularly when the text is qute small. Sans-serif fonts can be displayed clearly with less interference from factors such as screen resolution and font size.
None of this means that sans-serif is good and serif bad. The suitability of the typeface matters more than whether it is serif or sans-serif. The reader needs to be able to differentiate, for example, ‘l’ from ‘i’ when the two letters are side by side, for example. That isn’t easy with every sans-serif font. Verdana is popular for a good reason: it was designed for use on computer screens, and it is very easy to read.
Feel the width
One of the points which is as true on a screen as on the printed page is that the width of the text affects its readability. The longer each line of text is, the more likely the eye will lose its place when flicking back to the beginning of the next line. There are plenty of web sites out there which ignore this, spreading the text across the entire width of the browser window. The same problem occurs when body text is centre-aligned — an appalling technique which was inexplicably popular some years ago. Another problem sometimes encountered is the text which is too narrow:
This does
happen, and it
makes the text
very hard to
read because
it is so broken
up.
The optimum width for text is in the region of 10cm on paper. With average font sizes, that’s about 40–50 characters. An easier way to estimate it for the screen is to look at the number of words on a line: aim for an average of about 12; if it’s more than 15, the lines are getting too long. Obviously, this depends on the size of the text…
12pt?
Printed text is often in the 10–12pt range. I’ve just picked up a copy of Pratchett’s Sourcery and I see that it has been set in 10/11pt Palatino; that is a comfortable size for a reader with average eyesight. So is 10pt or 12pt text what you want on screen?
The first thing to note is that the point has a specific meaning in relation to print: it is one-twelfth of a pica (which is 0.166in). It does not bear any relation to the world of the world of the computer screen, where the measure for everything is the pixel. So, do we want to specify the font size in pixels, then? Is it 12px text we want? Er…
This is where we have to face up to a crucial difference between the printed word and the Web. A difference which, frankly, a lot of designers have refused to accept. When producing a book or a magazine, or even a pamphlet or newsletter, you have absolute control. Absolute control is something you don’t have with a web page — nor are you ever going to get it.
Why don’t I have control?
Most people have no concept of how much variation there is in the ways people access web pages. The first time they write a web page, they get it looking fantastic on the browser they use, at the screen resolution they use. Most of the time now the browser is some version of Internet Explorer.
The problem arises when someone turns up using Netscape — or Opera, or CyberDog, or Voyager, or… well, you get the idea — and the page doesn’t look good. It may look a mess, in fact. If they are really unlucky, it will be unreadable.
And then there is the question of screen resolution. Perhaps the page’s designer runs a monitor at 640×480. In that case, 12px might be readable. That won’t be the case if I come along with a monitor set to 1024×768 (or an even higher resolution): the 12px text will be tiny.
Just in case you think that matters aren’t complicated enough, the user’s platform can have an effect. Suppose you have designed a page and using CSS have set font sizes using points (because, as with many people, you are familiar with points from the world of print).
You are designing on a PC. You have some text you want to be small (for legitimate reasons), so you make it 9pt. All is well until you get irate messages from Mac users complaining about text so small it is a meaningless jumble of tiny marks.
Or: you are designing on a Mac. You set your main body text to 14pt or 16pt. It looks great. And then you start getting derisory messages from PC users about the enormous text on the page.
What’s going on?
The problem is that Mac browsers have traditionally worked at 72dpi (in which, basically, 1px=1pt) whereas Windows browsers work at 96dpi. On a Mac, 12pt text and 12px text are the same size. On a Windows machine, the 12pt text will be significantly larger than the 12px text — more like 14px. Here’s an example (it needs CSS):
This text is defined using font-size: 14pt;. On a Mac it should look the same size as the following text (but see below); on a PC it will be markedly larger.
This text is defined using font-size: 14px;. It should look the same size on a Mac and a PC; on a Mac, it will be the same size as the previous text (but see below); on a PC it will be noticeably smaller.
Today, though, you may find that you are using a Mac and the two examples are not the same size. If you are using IE5 or Netscape 6, these browsers can be set to either 72dpi or 96dpi — and the default is 96dpi, so with these browsers you may see something similar to what a Windows user sees, depending on how you have set your preferences.
Not every Mac user has one of these browsers, of course, and not every Mac user who does will leave the settings at the defaults. This cross-platform variation is one reason to avoid using points in setting the size of text. There are others, which we’ll come to later.
The font element
The first tool web authors had to format text was the <font> tag. As well as allowing the selection of a set of font faces, it allowed some sizing of text, either using absolute or relative values. Before going any further, it is important to emphasise that the <font> element is deprecated, i.e. it should not be used. It is permitted in the transitional DTDs of HTML 4 and XHTML 1.0 for backwards compatibility alone; ultimately, it will go the way of the dodo.
The reason behind this is that HTML is designed to be a structural description of a document, not a language for defining the document’s presentation. In the strict DTDs of HTML 4 and XHTML 1.0, <font> and other presentational elements are not allowed.
The absolute sizing in the <font> element measures the size of type in a scale from 1 to 7. The default size, specified by the browser preferences, is 3. You cannot set font sizes in HTML using pixels, points or any other such measurement.
Relative sizing with <font> uses positive or negative integers. The adjustment of the size is always relative to the default (or basefont-set) size. Here are two examples:
<font size="4">This text would be 20% bigger than the default text.</font> <font size="+1">This text would also be 20% bigger than the default text.</font>
Thus <font size="+4"> gives the same results as <font size="7"> and <font size="-2"> the same results as <font size="1">, and so on.
Type is never displayed larger than 7 or smaller than 1, no matter what relative values you attempt to give the size attribute.
Let me repeat: the adjustment of text size with relative values is always relative to the default size. Nesting <font> tags has no effect on this. If the default text size is 3, <font size="+1"> will produce size 4 text even if enclosed within another <font> tag which sets a higher size:
<font size="6">This text is size 6. <font size="+1">But this text is size 4.</font> And this text is size 6.</font>
But, as already noted, <font> is deprecated, and if the W3C has its way it will disappear — and with it will go a lot of headaches for web designers, to be honest. In the modern world, we have…
Cascading Style Sheets
CSS is not fully supported as yet by any browser, but the ability to set font sizes and typefaces is well supported by fourth generation and later browsers. We’re not going to go deeply into CSS here, but we’ll take a look at the way it handles text size. There are four approaches in CSS to sizing text.
- Absolute size
- This causes a bit of confusion because most people think that “absolute size” refers to the use of pixels or points. In fact, it is reminiscent of the absolute size system used with the
<font>tag. Absolute size values are:xx-small,x-small,small,medium,large,x-largeandxx-large. - Relative sizes
- Confusion again — most people probably think “relative sizes” refers to the use of ems or percentages. There are only two relative values for sizes in CSS:
largerandsmaller. These modify the type size relative to the parent object. - Length sizes
- This is the sizing of text using a numerical value plus a particular unit, such as 12px or 12pt. It is important to note that in CSS
font-size: 12;is not valid — the units used must be specified. The units which can be used are:- cm: Centimetres.
- em: The em is the size of ‘M’ in the font in question — basically, it is the size of the font; 1em is the default size for the document or element in question.
- ex: This is the width of ‘x’ in the font in question.
- in: Inches.
- mm: Millimetres; 1mm = 0.1cm.
- pc: Pica, a measure from the print world equal to a sixth of an inch.
- pt: Point — a twelfth of a pica.
- px: Pixels, or picture elements. This is the one unit of measure which relates specifically to the computer screen. [N.B. – the measurement pixel is not identical to display pixels.]
- Percentage sizes
- Using percentage sizes specifies the size of the text as a percentage of the default size of the parent element.
Which to use?
Most of the time, it is length sizes which people use and discuss, occasionally with percentage sizes. Within length sizes, pixels and points are often described as “absolute”, while ems would, like percentages, be seen as “relative”. This isn’t technically correct, but it does make sense.
It does not make any sense to use units such as centimetres or inches for text being displayed on a screen. As we’ve seen, even point sizes are variable across systems. What is the standard for using inches in this context? Now, in a style sheet used to control the appearance of a hard copy, it may make a lot of sense to use centimetres, millimetres or inches (or points, for that matter) — but not for the screen.
Points can vary from platfrom to platform; like pica, they are units derived from printing which don’t necessarily translate well to the screen. On the other hand, pixels do have a meaning in relation to computer displays — but there are other problems with pixels.
Some older (but not all that old) browsers can’t resize text sized in pixels. True, some can’t resize text sized in points either, but the situation is even worse for pixels. That is not so bad if the text is readable, but if — as is often the case — the text is too small (“because it looks coool”), then it’s stuck that way. Tough titty if you can’t read it. Some browsers also have trouble producing printouts with pixel-sized text.
The principal objection, though, to the use of pixels or points is that it is an attempt to set an absolute size for the text irrespective of the users’ needs. 10px text may be fine for you and your eyesight on a 640×480 display, it may be barely visible to someone with poorer eyesight on a 1024×768 display.
Give up control
The approach recommended by the W3C and many others is to give control to the user. If the user has set the default text size to 16px, he’s done that for a reason. Overriding that may at least cause irritation, at worst it will make the page unusable.
So the recommended approach is to use ems or percentages — as these work relative to the default size, then the relative sizes of different sections of the page can be maintained while working to the user’s preferences. It should go without saying that the main body text should be 1em (or 100%).
The snag which arises is that some browsers don’t handle ems or percentages terribly well. Some versions of Netscape have a bad reputation in this respect. A workaround for that would be to use two style sheets: link to one using the <link> tag (this is for Netscape 4), and then import the style sheet for more modern browsers. Because Netscape 4 doesn’t understand @import it will ignore it, while the modern browsers will replace the style rules in the linked stylesheet with those in the imported one.
In fact, that’s the method used here. The Netscape 4 stylesheet uses pixels (because that works in Netscape 4 and avoids the cross-platform problem described earlier); the main stylesheet is imported and uses ems, for the most part, to set text size. As Netscape 4 declines in use, it will be possible to remove that stylesheet and simply use the linked one with its relatively sized text. But that’ll be a while down the road.
© DC 2000, 2001. All rights reserved.
