Re: font sizes in ems
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:
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
> 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.
The printed page transcends space and time. The printed page, the
infinitude of books, must be transcended. THE ELECTRO-LIBRARY.
--El Lissitzky, 1923