|
||||||||
|
CSS offers a bewildering variety of units: real-world lengths, such as inches; typographical units, such as points, picas and exes; and relative units, such as percentages, ems and pixels.
With such an array of units, and very few of any use, it is very easy to choose the wrong one. This master class helps ensure you make the right decision.
To start with, you might decide to use one of the real-world lengths, simply because you've used them all your life.
A little thought, however, reveals that this is a bad idea, since it fails to take into account the size of the screen on which the user is viewing the page - 1 inch might be the right size for a 21" Web TV, but it would be absurd on a palmtop or computer monitor. Even if you restrict your styles to computer screens, by use of the media attribute (e.g., <STYLE type="text/css" media="screen"> or <LINK rel="stylesheet" type="text/css" media="screen">), there will still be enormous differences between different mointors - what looks good at 640 * 480 resolution on a 14" monitor will look bad on a 17" monitor at 1024 * 768.
And if that wasn't bad enough, the browsers don't even get 1 inch (or 0.5cm or 26mm or whatever) correct.
This is because for a browser to produce one inch, they must know the size of the monitor, but they don't. What actually happens when an application requests a font of say 1inch in height is that the operating system converts this to a number of pixels.
This number of pixels never corresponds to the number required to render one inch, but instead to the computer's pixels per inch setting. To give an example, the monitor on which I am viewing this is 11" wide by 8" high, and is running at 800 by 600 resolution. My display driver is set to 96 pixels per inch, and so therefore when something that is one inch high is requested by a browser, what will be rendered is 96 pixels high. However, one inch high actually corresponds to 600/8 = 75 pixels, so when someone specifies font-size: 1in, what they are actually getting is 1.28 inches.
If I used a Macintosh, however, chances are that my display driver would be set to 72 pixels per inch. This doesn't mean that Macintosh applications have smaller text, since it is normal for applications to specify fonts in terms of pixels, but what it does mean is that with the same monitor attached to a Macintosh, what would be rendered would be 0.96 inches high.
Thus you can see that not only is it a bad idea to use real-world lengths, because of differences in sizes of screen, viewing distance, etc., it is also a bad idea because different operating systems (or even the same operating system with different settings (120 ppi is not unheard of)) display fonts in the same way.
I am sure you are now convinced of the folly of using real-world lengths (but then you'd probably realized that already). The next unit to consider is the point - you might think that it's a good idea to use them, probably because you are familiar with them from word processors or desktop publishing programs.
In fact, these are just as bad as real-world lengths. To see that this is so, you must realise what the CSS specification defines the point as.
The definition given is that one pixel is equal to 1/72nd of an inch. This means that when you say font-size: 12pt, you are actually saying font-size: 1/6in. We've seen already what a bad idea this is, but if you need further convincing, if you are using a machine that has 96ppi (as you almost certainly will be if you are using Windows - to check load up Control Panel, double click Display, then click the Settings tab. Next click on the Fonts dropdown menu, and select Other. This will show the ppi setting, and will allow you to change it), simply change all your references to points to pixels to simulate (most) Macintosh machines (since they usually have 72ppi). I'm sure you'll find that the experience cures you of your desire to use points for evermore.
Equally, if you normally use 72ppi, simply add a third to all your points references, and you will see the error of your ways.
All of this means that in all browsers, like the real-world lengths, points (and picas (a pica is equal to 12 points)) are broken by the operating system, and therefore can't be fixed by the browser, and since they are broken and can't be fixed, you shouldn't use them.
At last we have come onto a unit that is not completely useless. The ex is defined in CSS as the height of the font's 'x' glyph. This allows you to relate sizes to the apparent size of a font, rather than its actual size.
The value for x-height varies from font to font - if you've ever used script fonts, you will probably have noticed that they appear to be much smaller than normal fonts at the same specified font size: this is due to script fonts generally having an x-height of around 3/10 of font size, whereas regular fonts are usually about 1/2 of font size.
These differences seem to endow the ex with great utility - what could be more useful than a unit that actually relates to the 'real' size rather than some notional specified value.
However, closer examination reveals that there are actually very few properties where the ex is useful. Here's an evaluation for each:
Property | Useful? |
---|---|
Font sizes | No; with font sizes it is generally required to say 'A font 25% larger than the parent element' or 'The same size as the parent element' - not possible with the ex. |
Heights/min/max heights | No |
Marker-offset | No |
Widths/min/max widths | No |
Line heights | No; with line heights, the actual font-size is required. |
Clip | No |
Top, right, left, bottom | No |
Background positions | No |
Margins and padding | Not on horizontal ones; o.k, on vertical ones (but not on @page), but the em is better. |
Text shadows | Yes; probably the best unit, although the em is acceptable. |
Border and outline widths | Yes |
Vertical-align | Yes |
Having considered the ex on a theoretical level, I am sad to say that in no browser is it correctly implemented, and therefore, although you may use it in your master style sheet (see RichInStyle.com's article on cross-browser style if you haven't got one), you should avoid it in any actual browser until one is released that supports it. This is so because all browsers (except Internet Explorer 3, which interprets it as 1pt) interpret it as .5em, which is wrong - it can be as much as .6em, but as little as .3em.
Without doubt, the em is one of the best of all the CSS units. However, it carries with it a couple of minor difficulties. The first of these is the confusion with the common typographical sense of the term (a perennial problem throughout CSS - by providing so many units that are useful in typographical circles (e.g., the point, which is great when you are printing a book since, partially sighted people not withstanding, you can be sure that everyone reads a book at roughly the same distance from their face; and thus can ensure that when you specify 12 points, it will appear the same to everyone, etc.), but which either have totally different meanings or are useless in the computer world, confusion is inevitable) - in typography an em is the width of a lowercase em.
In CSS, however, this most assuredly is not the case. CSS defines 1em as being equal to the element's font-size, except when specified on font-size, where it is equal to the font-size of the element's parent. If the element does not have an ancestor (e.g., the element is the HTML element), 1em is equal to the user's preferred font size.
As a result, the em is most useful of all the units. It is the only unit that should be used on font-size (% is equally acceptable, but is not a unit), because it ensures that everything is in proportion, and, just as crucially, that everything relates to the size with which the user is comfortable.
The importance of this cannot be understated - your users will thank you for being considerate of their preferences. Here is a demonstration of how it does this:
<HTML> <HEAD> <STYLE type="text/css"> BIG {font-size: 1.2em} </STYLE> </HEAD> <BODY> <P> Some text <BIG>that is bigger</BIG> </P> </BODY> </HEAD>
BIG's text is 1.2 times as big as P's. P, lacking a font size declaration, inherits BODY's value. BODY also lacks a font size declaration, so inherits from HTML, which in turn lacks a font size declaration. As a result, HTML's font size is the initial value of font-size, which will be the size that the user prefers, and therefore BIG is 1.2 times as large as the user's preferred font - something that can't be achieved with pixels, points, etc.
Here, again, is a list of the properties, and an evaluation of whether you should use the em with them:
Property | Useful? |
---|---|
Font sizes | Yes, yes, yes! |
Heights/min/max heights | Sometimes; useful, for example, for saying that height should be a certain number of times bigger than line-height; e.g., TEXTAREA {font-size: 0.9em; line-height: 1.2em; height: 3.24em (i.e., since line-height: 1.2em is 0.9em * 1.2 = 1.08em, so to get a height equal to three lines, height: 3.24em is needed). |
Marker-offset | Yes |
Widths/min/max widths | No |
Line heights | Usually not; <number> is better, unless you want a fixed line height that is not affected by an element's inline content; acceptable if the element does not contain content that is larger (headings are an example of such an element). |
Clip | Yes |
Top, right, left, bottom | On relative positioning only |
Background positions | No |
Margins and padding | No on horizontal ones; yes on vertical ones (but not on @page) |
Text shadows | Yes; but the ex is better |
Border and outline widths | Yes; but the ex may be better |
Vertical-align | Yes; but the ex may be better |
Finally, having said this, I must stop to point out that Internet Explorer 3 does not support the em at all, interpreting it as 1 point, and Netscape 4's implementation is very badly buggy - so buggy as to be unusable. As a result, if you have separate style sheets for each browser, or simply use @import to exclude Netscape and IE 3, you should avoid the em in the Netscape 4 and Internet Explorer 3 style sheet. If you do not follow either of these approaches (which you can read about in RichInStyle.com's cross-browser guide), but only have one style sheet - one that you allow to be read by Internet Explorer 3 and Netscape (there are techniques for excluding them, which you can read about in RichInStyle.com's cross-browser guide), then you must avoid the em.
The pixel is a much underrated unit, suffering greatly from ignorance as to its meaning. Many
people assume that the pixel is as bad as real-world lengths. In actual fact this is not so - the
pixel is a relative unit, since it relates to the resolution of the monitor (cf.
ems, which relate originally to the user's preferences). To emphasize how much better than the
point it is, consider font-size: 72pt
. This would be rendered on a machine with 96ppi
(typically a Windows machine) as 96px, but on a machine with 72ppi (note that the ppi figures
provided by Windows and the Mac OS are not true ppi figures (the true figures are calculated by
ppi=vertical pixels/height or ppi=horizontal pixels/width, and as such can only be affected by
changing screen resolution or by changing monitor), but are conversion factors used to convert from real-world
lengths to pixels) as 72px. Thus the same size is rendered 33% larger in one machine than the
other, but if you had just specified font-size: 96px
, then 96 pixels would be rendered
on both machines.
As a result, although other units are always better in theory, in practice they are too badly broken in one browser or another, and therefore the pixel is the only unit that is of any use in style sheets intended for general consumption.
Better still, font-size: 17px will look just as appropriate at 1024 * 768 as at 640 * 480. This is because people who have high resolutions set either have larger monitors, in which case the pixels will be larger anyway, or prefer smaller sizes, and will thus be as happy with font-size: 17px on their higher resolution as someone else is on their low-res machine.
Best yet, the CSS specification states that if the output device pixel differs greatly from the specification's reference pixel, it should be scaled. As a result, when someone prints your page on a 300dpi printer, font-size: 18px will not be printed as font-size: 18 dots, but at the size that looks the same at the viewing distance of paper as a 18px font on a 90ppi monitor viewed at a monitor's typical viewing distance (arm's length); which is 45 printed dots. This scaling is carried out by print drivers before printing.
However, no browser performs any kind of scaling when displaying on screen, principally because they have no information about the true ppi value - to scale using the OS' ppi value would be false, since it never bears any relation to the true value. This is somewhat unfortunate, since if browsers had access to this information, then font-size: 17px would look exactly the same on every output medium.
Pixel units in theory provide that what the viewer will see should have exactly the same apparent size to them as to the author of the page. In this sense they, unlike the absolute lengths, present no cross-media difficulties, but do, in theory, present accessibility difficulties in the same way that a book that isn't large print presents accessibility difficulties. However, there is a large extent to which, by browsers' inability to scale pixel values, that these accessibility difficulties are avoided, since people tend to select the resolution at which they can read the screen most easily, and therefore values specified in pixels will look equally appropriate on everyone's computer.
There is one important note before leaving the topic of pixels, and that is that you must include the px - font-size: 17 (or similar) is meaningless and will be ignored by compliant browsers). Unfortunately many so-called experts fail to do this, and bad habits are reinforced. If you want to join the idiots club, omit the unit; if you don't, include it.
In conclusion, if your style sheet is designed for all browsers, you should use pixels. If, however, you use multiple style sheets, you should use ems and % for Opera and Internet Explorer 4 and 5, and pixels for Netscape 4 and Internet Explorer 3.
The percentage isn't really a unit at all, but specifies the value relative to another value, usually the parent element or containing block. Here is an evaluation of it for each property:
Property | Useful? |
---|---|
Font sizes | Yes |
Heights/min/max heights | Rarely - only has an effect if the containing block has height set to a specific value |
Marker-offset | Not valid |
Widths/min/max widths | Yes |
Line heights | Usually not; <number> is better, unless you want a fixed line height that is not affected by an element's inline content, or if the element does not contain content that is larger. |
Clip | Not valid |
Top, right, left, bottom | Yes |
Background positions | Yes |
Margins and padding | Yes on horizontal ones; no on vertical ones (except on @page) |
Text shadows | Not valid |
Border and outline widths | Not valid |
Vertical-align | Yes (relates to line-height) |
The main trouble with the percentage is that it is very buggy - only Opera and IE 5 have no problems with it. Internet Explorer 4 only gets it right on width and line-height and Internet Explorer 3 and Netscape never at all.
There is one final point of note before leaving the subject of units, and that is that you must never have a space between the amount and the unit - margin-left: 10 % is invalid, and will be ignored - correct would be margin: 10%.
The next section of this master class deals with fonts. To read about them, click here.
Copyright © RichInStyle.com 2000; all rights reserved. See copyright document for terms of use. Please visit Bukit Lawang flood appeal.