- From: Tantek Celik <tantek@cs.stanford.edu>
- Date: Mon, 22 Nov 1999 16:27:54 -0800
- To: "L. David Baron" <dbaron@fas.harvard.edu>, dbaron@fas.harvard.edu, erik@netscape.com
- CC: fahrner@pobox.com, "www-style@w3.org" <www-style@w3.org>
>> Those units are defined in terms of "font size", and since font-size
>> corresponds to "em", I think those units should continue to be based on
>> the em, rather than the maximum height of the glyphs.
>
> The reason I think this is a bad idea is that it is not backwards
> compatible with most current behavior, and the current behavior makes
> any line-height above 1.0 "safe" (i.e., it cannot cause overlap).
Not the "current behavior" in IE for Mac. It is certainly possible to have
a font which is rendering long flourishes etc. far outside of its em-height
which overlaps with adjacent lines of text formatted at line-height:1.0 or
even a bit higher.
> This
> would mean that things that were once reasonable suggestions could now
> be unsafe.
They are "unsafe" as you say, right now, with shipping browsers, today.
> Since scaling factors (i.e., 'normal' or a number) are the only safe
> way of suggesting line-height because of inheritance, I think they should
> be kept safe in all respects.
I disagree with the general philosophy that it is CSS's responsibility to be
"kept safe". We should make things easy to understand and author to, but
not go out of our way to restrict flexibility and empowerment.
Who are we to decide what is safe and what is art?
>> If we need a way to refer to the max height of the font, let's introduce
>> a new unit called "mx" (or whatever). E.g. the following sets the
>> line-height to 1.04 times the max height of the font:
>>
>> P { line-height: 1.04mx }
>
> New units can't be introduced to CSS for at least 4 years or so in any
> useful way, since many existing browsers will treat them as pixels.
That would be in violation of CSS1 Section 7.1 Forward Compatible parsing,
now wouldn't it?
Tantek
Received on Monday, 22 November 1999 19:28:52 UTC