|
||||||||
|
Coping with browsers that don't support the em
One of the most important decisions in typography is the line height that you wish to use. Your decision in this matter will make a vast difference to a page.
However, before one can proceed in this direction, it is first necessary to survey the methods of specifying line heights using CSS.
The property that CSS provides for specifying line heights is, unsuprisingly,
line-height. I recommend that you specify this property on all block
elements except for BODY, PRE and H1-6. On these elements I recommend that you specify line height
via the font shorthand. I recommend that you do not declare line height on HTML at
all.
I make these recommendations for several reasons:
font-size: 1em on BODY (i.e., as opposed to font-size: 1.2em) or 0.9em or whatever), which serves no
purpose (and therefore can be omitted), since you should always specify a font family on BODY, it
is shorter to use the font shorthand than to declare both line-height and font-size. For example,
compare BODY {line-height: 1.2; font-family: sans-serif} with BODY {font:
1em/1.2 sans-serif} [Footnote1].The font shorthand is a little more complicated than most, so here's a quick reminder: Font
requires that both font size and family are specified; therefore, font: bold 1em is wrong, as is
font: bold sans-serif. In addition, the family must be last - font: 1em
Arial, sans-serif, not font: Arial, sans-serif 1em; and size must be second to
last; for example, font: 1em Arial, not font: 1em bold Arial. If you
specify line height using font, this is done by following the size with a / and the line height -
font: 1em/1.3 Arial (not font: 1em/ 1.3 Arial).
You should always specify line heights using <number>. This number specifies the number of times larger than font-size that the line-height should be. It differs from specifying in ems insofar as when you specify a line height in ems, the calculated value is inherited, when specified using <number>, the number is inherited - if you specify P {font: 1em/1.6em sans-serif} and had SPAN.insideP {font-size: 1.5em}, then the SPAN would looked cramped since the line height of the line that it would be on would be 1.6 times as large as P. If, on the other hand, you had specified P {font: 1em/1.6 sans-serif}, the factor of 1.6 would be inherited to the SPAN element, thereby making the height of its line appropriate for it.
Adjusting line height makes a vast difference to pages, one you probably wouldn't realise until you actually change it.
Typically in paper publishing a line height about 1.2 times as large as font size is chosen. Such low factors are chosen to reduce paper costs. For glossy computer books, however, it is desirable to fill as much as paper as possible so that they can charge you $50 for it, and a factor up around 1.5 is used.
In the computer world, however, none of the considerations of the printed page are relevant - screen space is free. As a result, the temptation is to whack line height up as high as it will go, the thinking being that more is better. However, this is not so - there are diminishing returns beyond a certain point.
The role of line-height is to make the general appearance of a page more attractive - the white space between the lines makes the page easier on the eye. However, while the general impression that a page gives is improved by increasing line heights, the readability may not be - if line-height is set too high, readability is actually impaired. Similar principles apply here to those of outrageous color schemes - while the page may have an initial 'Wow!' factor, it is likely that the reader will soon tire of it.
Excessive line heights mean that instead of drawing the eye across and down the page, it is simply drawn down the page, with the reader encouraged to skim read the page rather than reading it properly.
As a result, you should take care that you set line height to a setting that causes natural progression of the eye across the page and from line-to-line.
To see some of these principles in action, why not compare these two pages, both of which have similar content in terms of length, etc. Here's one that has a large line height (demonstration requires Internet Explorer 4 or better, Opera 3.50 or better, or Netscape 4 or better). Take a look at it.
Now compare it with this one, which has a smaller line height.
While there is no doubt that the first extract was the more attractive looking of the two, you will almost certainly have noticed that the second was easier to read. The first extract had line-height: 1.6, and the second line-height: 1.2 (the default in most known browsers).
The reason that the second was easier to read despite being far more cramped, was that their was little white space to serve as a distraction.
Now take a look at this demonstration page with a large line height.
Compare it with this one with a smaller line height.
The difference between the two is astounding, and yet, as before, one had line-height: 1.6, and the other line-height: 1.2.
The difference is due to the differing colors - in the first set of demos, it was plain black on white, but in this case it is yellow on black. The effect of the dark color is to make the lines appear closer together, and thus make the page look cramped. With the bright white, however, the appearance is given of acres more space. In addition, with the white, there is a greater tendency for the eye to be carried down the page.
These differences lead one to draw two conclusions: firstly that with white backgrounds one should take care not to set line heights to high, and secondly that with darker background the opposite is true.
A possible way of maximizing line height, and therefore making a page appear more attractive is through setting the background color to a rich but light color so that it is easier on the eye. Here's an example, with a purple background, and here again with the smaller line height..
A further factor that affects the appropriate line height is the actual font itself. As explained in the master class on units, some fonts have a smaller x-height than others, and therefore appear smaller at the same font size. However, line heights must relate to the maximum font size to avoid overlap, etc. As a result, fonts with larger x-heights need larger line height factors (Verdana's x-height is 0.58(font-size), Times New Roman's only .46(font-size)).
One of the most important factors in determining line height is the type of content in a document. For example, if you have a document that presents a large quantity of information, then a large line height is appropriate; anything up to 1.5 with white backgrounds, greater still with darker backgrounds. However, if you are presenting less information, as on a navigational page, lower factors are appropriate.
In addition, it is generally appropriate to have lower line heights on headings and table cells; in the first instance because they generally consists of fewer lines than P and LI, and in the second instance because the content does not need to appear as 'clean'.
Equally, it is generally appropriate to have lower line heights on computer code or other preformatted text - no more than about 1.3. Under certain circumstances, it might even be appropriate to set line height to 1, or even below - as on the navigational device at the top of this page. The reason for setting it below 1 is that most rendered glyphs are much smaller than the font size due to the need to have a space to put accents on (although in some fonts, the tallest glyph is taller than font size). As a result, you can set line-height to a value less than 1. It is inadvisable to cut this too fine, since someone else might not have the font that you specify, and might have a font with less 'internal leading', and so the line height, 'safe' in your font, might cause overlap in theirs.
In conclusion, although it is impossible to make any firm recommendations on matters of personal taste, I find a value around 1.4 yields attractive pages with white backgrounds in typical sans-serif fonts.
Line height is one of the most important of all properties. As a result, it is well worth investing some time reading RichInStyle.com's bug guides on the subject.
As a brief guide, you must never expose Internet Explorer 3 users to line-height declarations. To do so is entirely unacceptable - it is unacceptable to expose any user to any bugs in their software - it is not their fault that their software is buggy, but it certainly is your fault if, knowing the bugs exist, you expose them to them regardless.
In addition, you must never use %, ems or <number> in Netscape 4.* on line-height, but instead should use pixels (thereby implying that you must set font-size in pixels as well). If you do not heed this advice, it is inevitable that problems will ensue (for example, if you use points, cm, in, etc., the document will have a page break before and after every element when printed).
It is quite simple to provide the better browsers (Internet Explorer 4 and 5 and Opera 3.5 or newer) with better line-height declarations (i.e., using relative units). If you are using RichInStyle.com's free browser detection script, simply exclude line-height declarations from ie3.css, ie30.css and all.css, make declarations in pixels in nn4.css, and provide the other browsers with the ordinary declaration. For example,
P {line-height: 1.4}
Becomes:
all.css; ie3.css; ie30.css
P {}
nn4.css
P {font-size: 16px; /* See below */
line-height: 22px /* 16 * 1.4 = 22.4, which is 22px to the nearest pixel */ }
ie4.css; ie5.css; nn5.css; op3.css
P {line-height: 1.4}
Or if you follow the single style sheet route (discussed in RichInStyle.com's guide to cross-browser style):
@import url(okbrowsers.css);
@ie3away; /* Hide from IE 3 */
P {line-height: 22px;
font-size: 16px} /* Needed so that line-height is 1.4 times as large (see below for
reasoning behind the value selected) */
And in okbrowsers.css:
BODY P {line-height: 1.4;
font-size: 1em} /* BODY is so that the declarations have greater specificity and therefore override the ones in the main style sheet. */
There is a further bug in Netscape, whereby setting a border on an element resets line-height to
normal. This bug is suppressed by setting the element's left margin to any value
including 0.
There are also some minor glitches in most browsers relating to lines that have inline images. These are practically undetectable, and have not been known to cause any problems. Finally, there is a glitch in Opera whereby the half leading is applied below the baseline rather than below the bottom of the font. This means that the bottom line of every element hangs down ever so slightly (a few pixels) from where it should be. This bug is usually undetectable, but it was noticeable enough on RichInStyle.com's front page (the bottom of the descenders on the heading were overlapping the border slightly - not unattractive, but not desired either) to warrant adding an extra couple of pixels padding for Opera only.
It is generally agreed that on the web (compared to the printed page, where serif fonts are undoubtedly king (the reason for the distinction being that although serif fonts are much easier on the eye, because of the limited number of pixels available on screen (typically 85 dpi as opposed to 1200 on a printed page), sans-serif fonts, with their simpler designs are more readable)), at least the body text should be in sans-serif (those without serifs, that is adornments to the font, cf. SERIF FONT and SANS-SERIF FONT) , but that the best heading fonts are those with serifs. Typical examples of each are Arial for sans-serif and Times for serif.
However, it is important on the world wide web that you use fonts that are clean and attractive, so you might consider putting heading fonts in sans-serif as well. Compare these two:
Some text that is in serif. It isn't very interesting, but is still useful. Some text that is in serif. It isn't very interesting, but is still useful. Some text that is in serif. It isn't very interesting, but is still useful. Some text that is in serif. It isn't very interesting, but is still useful. Some text that is in serif. It isn't very interesting, but is still useful. Some text that is in serif. It isn't very interesting, but is still useful. Some text that is in serif. It isn't very interesting, but is still useful.
Some text that is in sans-serif. It isn't very interesting, but is still useful. Some text that is in sans-serif. It isn't very interesting, but is still useful. Some text that is in sans-serif. It isn't very interesting, but is still useful. Some text that is in sans-serif. It isn't very interesting, but is still useful. Some text that is in sans-serif. It isn't very interesting, but is still useful. Some text that is in sans-serif. It isn't very interesting, but is still useful. Some text that is in sans-serif. It isn't very interesting, but is still useful.
I recommend that you select a sans-serif font for your body text, although the choice as to the best font for your headings is a matter of personal taste.
For dropcaps, I recommend a serif font and for computer code a monospaced font. In all this of course, it is important to avoid using too many fonts on a page, which tends to produce ugly pages.
It is definitely
worth specifying as many fonts as possible by font-family: Arial,
Geneva, Helvetica, sans-serif, or font: 1.5em Arial, Geneva,
Helvetica, sans-serif; where the
first font is the preferred font, the
second is the next-best font, etc. Ideally, you should
specify enough fonts
so that every user on every system has one of them. However, the last font
that you specify should be a generic font family (the generic font families
are
monospace (all letters are the same width so that the font
gets an ugly, compressed look -
only really useful for computer code),
sans-serif, fantasy (avoid - if
you need a fantasy
font, use named fonts instead - the result is dubious), cursive
(avoid - most browsers won't render this in a cursive font) and
serif) to ensure that every
browser gets a font that is at least
approximately correct.
So you've produced your page, and it looks nice - all the right fonts, etc. But does it look nice on someone else's computer?
To find out if it does, I advise that you should always include one of these fonts in each of your font declarations, as these are those that are present and usable on all Win 32 installations:
The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog.
Although there is no reason why you shouldn't use other fonts, these should be specified as well
- instead of font-family: "Arial Rounded MT Bold", Helvetica, sans-serif; try
font-family: "Arial Rounded MT Bold", Helvetica, the best of the six fonts listed above,
sans-serif;
There are relatively few browser-related issues relating to typefaces. However, there are some significant ones:
P
{font-family: "Times New Roman";}, not P {font-family: "Times New Roman"}.Fortunately, the issue of font sizes is not as fraught with difficulties as some other areas of World Wide Web typography. However, there remain some problems with which one must deal. Firstly, as you'll know if you've read RichInStyle.com's guide to units (if you haven't, I strongly recommend that you do), there is only one unit that can be exposed to the bugginess of Netscape 4 and Internet Explorer 3, and that is the pixel. All other browsers should be given the em.
There are many reasons why you should only use the em:
However, I strongly recommend that you do not deviate from the initial value for the main body of text in your document (legitimate circumstances under which you might have larger or smaller include headings, etc.). As a result, I recommend that you only set font size to a different value on CODE, BIG, SMALL, PRE, TT, KBD, SAMP, SUB, SUP, H1, H2, H3, H4, H5 or H6, as these are the elements that are generally given differently sized text.
On these elements, you should always set font-size, since there are great differences in size between different browsers. Therefore, as is done in RichInStyle.com's template file, I recommend that you ensure that everyone has a consistent view of your site by setting font-size on all of these elements. Thus:
CODE, KBD, TT, SAMP, PRE {font: .9em monospace}
BIG {font-size: 1.15em}
SMALL, SUB, SUP {font-size: .85em}
H1 {font: 2.01em sans-serif}
H2 {font: 1.75em sans-serif}
H3 {font: 1.52em sans-serif}
H4 {font: 1.32em sans-serif}
H5 {font: 1.15em sans-serif}
H6 {font: 1em sans-serif}
These represent my recommended font size for each element; however, clearly personal taste varies, and therefore these are in no way fixed values.
As you'll know if you've read RichInStyle.com's guide to units, the ex, pt, pc, in, cm and mm are completely useless for font-size, and so if you use these, you will deserve the abuse that will inevitably come from your users.
In addition to these, I strongly recommend that you avoid all of the font size keywords like the
plague. Those that you should not use are: smaller, larger,
xx-small, x-small, small, medium, large,
x-large and xx-large. These are to be avoided in favor of the em (the %
is equally acceptable; however, the em is the slightly more intuitive unit). The reason that I
recommend that you avoid them is that they suffer from serious bugs in all web browsers, and also
because they represent neither what you want (e.g., large is 50% larger in one browser than
another), nor what your user wants. As a result, they should be avoided.
To illustrate how to convert point references into pixel references, it is first necessary to know the ppi setting of your browser. Take a look at the three pieces of text below:
If you have 96ppi (highly likely if you are using Windows), then all the point references that you were formerly using can be converted to pixels by multiplying them by one and a third.
If you have 72ppi, then all point references simply can be changed to pixel references.
All Windows browsers ship with a default font size of 12 points. Since 99% of Windows machines are set to 96ppi, this works out (since 12 points is 1/6 of an inch (see RichInStyle.com's guide to units for more on this topic)) at 96*1/6 = 16px. Macintosh browsers are set to equivalent values.
We need to convert the em references to pixels so that they can be used by Netscape 4 and Internet Explorer 3. Previously this presented a problem in that H1 {font-size: 2em} was 2 * x, where x is an unknown quantity; however, we now have a default value (16 pixels) that we can use to resolve all the em references into pixels for the buggy browsers.
All that remains therefore is to add font-size: 16px to BODY (to ensure that when we state font-size: 32px, 32px is actually twice BODY).
If you've got separate style sheets for each browsers (see RichInStyle.com's guide to cross-browser style), then:
ie3.css, ie30.css, nn4.css, all.css
BODY {font-size: 16px} /* So we have something to refer to */
CODE, KBD, TT, SAMP, PRE {font: 14px /* 16*.9 */ monospace}
BIG {font-size: 18px} /* Note that you should add contextual selectors if BIG is used on text that
is smaller or larger already - e.g., H3 BIG {font-size: 28px}. However, it is unlikely that this
will be so */
SMALL, SUP, SUB {font-size: 14px} /* See comments under BIG */
H1 {font: 32px sans-serif}
H2 {font: 28px sans-serif}
H3 {font: 24px sans-serif}
H4 {font: 21px sans-serif}
H5 {font: 18px sans-serif}
H6 {font: 16px sans-serif}
op3.css, ie4.css, ie5.css, nn5.css
BODY {font-size: 1em} /* To override the font-size: 16px - these browsers will read all.css so that
they get style if they don't have javascript enabled */
CODE, KBD, TT, SAMP, PRE {font: .9em monospace}
BIG {font-size: 1.15em}
SMALL, SUP, SUB {font-size: .85em}
H1 {font: 2.01em sans-serif}
H2 {font: 1.75em sans-serif}
H3 {font: 1.52em sans-serif}
H4 {font: 1.32em sans-serif}
H5 {font: 1.15em sans-serif}
H6 {font: 1em sans-serif}
If you haven't got separate style sheets for each browser, either use all.css, or, using the techniques detailed in RichInStyle.com's guide to cross-browser style use something like this:
@import url(okbrowsers.css);
/* Buggy browsers get */
BODY {font-size: 16px} /* So we have something to refer to */
CODE, KBD, TT, SAMP, PRE {font: 14px /* 16*.9 */ monospace}
BIG {font-size: 18px} /* Note that you should add contextual selectors if BIG is used on text that
is smaller or larger already - e.g., H3 BIG {font-size: 28px}. However, it is unlikely that this
will be so */
SMALL, SUP, SUB {font-size: 14px} /* See comments under BIG */
H1 {font: 32px sans-serif}
H2 {font: 28px sans-serif}
H3 {font: 24px sans-serif}
H4 {font: 21px sans-serif}
H5 {font: 18px sans-serif}
H6 {font: 16px sans-serif}
/* Okbrowsers.css - better browers get */
HTML BODY {font-size: 1em} /* HTML is added to give the declaration greater specificity so that it overrides the other values */
HTML CODE, HTML KBD, HTML TT, HTML SAMP, HTML PRE {font: .9em monospace}
HTML BIG {font-size: 1.15em}
HTML SMALL, HTML SUB, HTML SUP {font-size: .85em}
HTML H1 {font: 2.01em sans-serift}
HTML H2 {font: 1.75em sans-serif}
HTML H3 {font: 1.52em sans-serif}
HTML H4 {font: 1.32em sans-serif}
HTML H5 {font: 1.15em sans-serif}
HTML H6 {font: 1em sans-serif}
CSS presents a substantial number of ways with which one can adorn text. However, as always, most of them are little use. Here's a resumé:
1. [Note that technically if your HTML is top notch (i.e., you have:
<BODY> <H1>Heading</H1> <P> Paragraph <P> Paragraph </BODY>
Rather than:
<BODY> <H1>Heading</H1> Paragraph <P> Paragraph </BODY>
- enclosing all your paragraphs in P elements (tags are different from elements - tags specify the start and end of elements - with the P element, the <P> signifies the start of the element, and the </P> element the end (if the </P> tag is omitted, the next block element implies it))), you can omit line-height altogether, since you can specify it on P instead, and only declare font-family on BODY.]
That's the end of this part of the RichInStyle.com CSS masterclass; to continue to the next section, click here.
Copyright © RichInStyle.com 2000; all rights reserved. See copyright document for terms of use. Please visit Bukit Lawang flood appeal.