Re: When is an 'em' an 'em' ?

(forwarded from news: comp.infosystems.www.authoring.stylesheets )

(A copy of this message has also been posted to the following newsgroups:
comp.infosystems.www.authoring.stylesheets)

In article <34381c9c.83552011@news1.tninet.se>, d.tek.jre@ebox.tninet.se
(Jan Roland Eriksson) wrote:

" Take this as an example...
" 
" .doc-title {
"    font-size: 1.3em;
"    font-family: Verdana, sans-serif;
"    font-weight: bold;
"    margin-top: 7em;
"    margin-bottom: 0;
"    text-align: center
" }
" 
" In my BODY rule I have _not_ made any attempt to change the
" users defined size of font. As I understand it I should now
" expect
" 
" <H1 CLASS="doc-title">Some title</H>
" 
" to render in a font size of 1.3 x User font size.
" 
" But my question is, what should be expected as the rendered
" size of the top margin for "Some title"? (provided that any
" element above <H1>..</H1> has {margin-bottom: 0} )
" 
" I see two possibillities here...
" 
" 1) Top margin = 7 x 1.3 x User font size
" 2) Top margin = 7 x User font size
" 
" Item 1) comes to mind as margins are not inherited and there
" is a change of font size (base for the em length) specified
" in the .doc-title rule already when we reach the top margin
" declaration.

I also believe this is the correct interpretation, and Microsoft evidently
agrees. One thing you left out, though, is the interaction with
line-height. Top-margin adds to line-height. Unless you specify some other
line height on H1 or a parent element, the actual top margin for your H1
element should be:

   7(1.3n) + 1.33(1.3n)

...where n is the user font size. The second term is the line-height for
H1, and the 1.33 value derives from that elusively ineradicable style
virus from CERN known as the Mosaic Browser Default Stylesheet <span
class="rant">- you know, the one that has caused most Web author/designers
to reject structural markup altogether, and that HTML specifications
incubate in murky generalities about "typical rendering"</span>. In this
stylesheet, 1.33em is the line height for most children of BODY. (I've
done lots of screen grabs from "unstyled" markup in both Netscape and IE
to isolate the MBDS virus, and transformed pixel counts into relative
units based on CSS's inheritance model from BODY (1em). See
http://www.verso.com/agitprop/corestyle/base.html ).

Note that when specified in CSS, IE4 fails to inherit line-height
properly, basing it on the font size set on BODY rather than that of
children elements. Note also that while the actual measured line-height is
1.33em, in IE4 you must specify 1.17em in CSS to reproduce this default
rendering. (This holds when the value on BODY is the default 12 pt - I
haven't confirmed whether the distortion is linear for other sizes).

" Personally I would like it better if item 2) was the truth
" of the matter, i.e. all new lengths in a rule to be
" calculated based on the parent value and then after the new
" results are obtained, be applied to the child element.

Why? It seems to me better as is because type size and line height have a
jointly intimate relation to legibility, visual heirarchy, and aesthetic
character, as reflected in the shorthand "font" notation, where they are
specified together. (While line-height and top-margin are separate
properties, they are indistinguishable to the eye for lines of type.) With
margins and line-height deriving from the current element's font size, a
user could easily scale a presentation while preserving all important
typographical relationships, provided all children of BODY have their
sizes specified in relation to one key figure: that on BODY itself.

I said "could" instead of "can" because, alas, the UI affordances for font
size in CSS browsers do not manipulate a resident default CSS1 stylesheet
according to the normal cascading rules, but operate in some more
mysterious fashion. For example, if an author specifies:

P  {
   font: 1em/1.2em;
   }

...and an IE4 user changes the font size from "medium" to "bigger" through
the UI, the font size will increase but the leading (line-height) will not
increase with it! With the above figures, this could well cause the lines
to collide, for a certain drop in legibility, with absurdity setting in at
"biggest".

Anyway I've gone on long enough. Cheers! 

AAAAAAAAAAAAAAAAUUUUUUUUUUUUUUGH!!!!!!!

______________________________________________________________________
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 Saturday, 25 October 1997 21:07:58 UTC