Re: em

At 5:14 PM -0400 6/17/00, travis wrote:
>in several examples, font-size or width is identified as a number followed
>by em (e.g., 10em). what's this mean?

Hi. Here's more than you wanted to know:

1em is the size of the parent element's font. So if you have, say, a 
strongly emphasized phrase (<strong>...</strong>) within a paragraph 
(<p>...</p>), and the paragraph's font-size is 10px, and the strong 
phrase is 1.5em, then the strong phrase's size works out to 15px.

And what if the paragraph itself is sized in em units, or isn't sized 
explicitly at all? Then look to the paragraph's parent, and so on all 
the way along the document tree until you hit the document root 
(html). And what if the root isn't sized, or is sized in ems? 
Generally, the root value is derived from the user's stylesheet (or 
browser settings). For this reason, em units are often cited as most 
user-friendly, since they may be (though are not necessarily) 
relative to a value preferred by the user.

In reality, the usefulness of the em unit has been betrayed by the 
prevalence of CSS implementations that fail to let font sizes (and 
random selections of other properties) inherit per spec into certain 
elements such as tables. All released versions of Netscape mess it 
up, for instance, but even in the latest version of Explorer for 
Windows (5.5 beta), it is necessary to select both TD and its 
ancestor DIV.foo to get all of the text below to display at a common 
size relative to whatever the parent's size is:

<div class="foo">
This is some text
   <table>
     <tr>
       <td>
       This is some more text
       </td>
     </tr>
   </table>
</div>

Microsoft's Windows Explorer team shows no sign of moving toward a 
fix, nor even of acknowledging this as the bug that it is. (Something 
about hypothetical rules in one's hypothetical UA default stylesheet, 
which, no, you can't see because it *is* merely hypothetical.) 
Meanwhile, fine products like the Macintosh version of Explorer get 
this right. The result is often that text will end up illegible (or 
at least ill-sized) in one implementation or another, so authors 
stick with less troublesome, verbose, deprecated font tags or 
user-hostile units such as points or pixels, which do not involve 
inheritance.

What's more, WinIE is showing a tendency toward greater and greater 
deviance from the spec in regards to inheritance of relative font 
sizes. In the case below, the triply-spanned text should be 42% the 
size of P (probably illegible), not the mere 75% that it appears.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<html>
  <head>
   <title>
     Nested percent font-sizes
   </title>
   <style type="text/css">
     span { font-size: .75em; }
   </style>
  </head>
  <body>
   <p>How big is this P text?
    <span>
     <span>
      <span>
       This text should be 42% the size of whatever P is
       (and is in several implementations), not 75% as in WinIE.
      </span>
     </span>
    </span>
   </p>
  </body>
</html>


My guess is that the WinIE team is trying to get rid of the pesky 
inheritance from em and percentage units because in many cases, 
authors quite reasonably want a unit system that is relative to user 
preferences alone, *not* dependent upon the document structure. Such 
a system already exists in CSS1, however: the font-size keyword 
system (xx-small - xx-large). It's just that WinIE previously 
destroyed the usefulness of this system by implementing "small" 
rather than "medium" as the initial value, as the spec requires. 
(Something about CSS having to resemble legacy implementations of the 
FONT tag more than even the CSS spec, as if CSS were merely an 
abstraction of something that existed already!) So they're 
cannibalizing ems/percentages rather than correcting the "legacy" 
implementation of the keywords. Listening to customers, taking 
liberties with standards, locking customers in to one's own products: 
business as usual.

--
Todd Fahrner

Received on Saturday, 17 June 2000 21:41:02 UTC