- From: Todd Fahrner <fahrner@pobox.com>
- Date: Thu, 17 Jul 1997 14:55:22 -0700
- To: Gayle Kidder <reddik@sandiego.com>
- Cc: davidp@earthlink.net, www-style@w3.org
At 1:07 PM -0700 7/17/1997, Gayle Kidder wrote: > An em (which is inadequately > defined in CSS1) is, as best I can understand, the total size of the > font, measured more or less from the bottom of the descenders to the top > of the ascenders, or roughly the width of a capital M in the font. > (Historically this gets very complicated, but let's start from there.) My understanding is that the historical em spans, as you say, from the tops of the ascenders to the bottoms of the descenders, but that there's also a little extra to accomodate accents on caps, and to assure that the descenders of one line do not actually touch the ascenders/accents in the following line when set without leading (literally strips of lead inserted between the rows of type-chunks). Capital Ms were typically cast on a chunk of lead whose face was square, where the width equaled this vertical distance. So the em width/height became a handy but loose unit of measure, like the proverbial breadbox, pinhead, city block, etc. But I do find the em to be a discouragingly murky concept, both in the spec and in implementations, and join you in your hope for clarification. I have tried specifying points and pixel sizes on <body>, and ems on everything else, hoping that the ems would inherit the body size as a base, but between terribly inconsistent implementations, cross-platform font metrics, an unclear spec, and general distraction, I concluded that it's a big flaming mess. Meanwhile, many clients and colleagues continue to call for GIF text in many places where good, consistent CSS implementations across platforms would suffice. <rant class="product suggestion">It does no good to set the display to 120+ ppi and say "see the problem - and what about cellphone browsers?", because Photoshop remains the primary design tool. I can hardly blame them. What else is there? The company that builds a DTD-aware visual stylesheet development tool will have to deploy a popular browser with a common cross-platform rendering model and a boatload of fonts first. And any company that can do that will be powerful enough to make "open standards" ring pretty hollow.</rant> > If I specify a font size of 1em, then, it comes out considerably larger > than the default body type size of the user. In IE3.01 for Mac, it comes out at the default size. > I've experimented with > several different default fonts and sizes and find that in order to > approximate the user's default size you need to specify something > between .6 and .8 em, with .8em being the most reliable conversion among > those I tested. This, of course, varies with the font... and to a > certain extent with the browser. For those of you who are interested, > I've posted a demo with an assortment of common Windows fonts at: > http://www.beachmedia.com/www/emsizes.html In case anybody's curious about how this appears on a Mac (both CSS implementations), I'll have a screen grab up within a few hours at http://pdf.verso.com/test/beachmedia.GIF . > Another typographer friend of mine has this to say: > "[Designating font sizes in ems] is literally nonsensical in > traditional terms. An em is a unit of space; 12pt is a unit of size ... > it is meaningful to say "a 12-pt em" or "a 12-pt font" but not a "1-em > font" -- the size of the em varies according the size of the font, not > vice versa." Typography's never cascaded before, though, except in the instance where DTP programs let you base styles on other styles (inheritance). It seems that the CSS inheritance model (as implemented so far, at least), varies considerably from the document tree model, though, so it's confusing. ________________________________________ Todd Fahrner mailto:fahrner@pobox.com http://www.verso.com/ The printed page transcends space and time. The printed page, the infinitude of books, must be transcended. THE ELECTRO-LIBRARY. --El Lissitzky, 1923
Received on Thursday, 17 July 1997 17:54:46 UTC