W3C home > Mailing lists > Public > www-style@w3.org > January 2000

What's an em (was RE: Units, font sizing, and zoom suggestion for CSS 3)

From: Karlsson Kent - keka <keka@im.se>
Date: Mon, 31 Jan 2000 18:21:35 +0100
Message-ID: <C110A2268F8DD111AA1A00805F85E58DA68574@ntgbg1>
To: www-style@w3.org
Cc: "'www-font@w3.org'" <www-font@w3.org>
What's an em?
=============


	(In summary: I still think there is a very good case for
	correcting(!) the definition of 'em' for CSS (3).  Note that 
	I also suggest adding new relative units 'line' and 'cap'.
	Yes, TeX is *the* main reason for still wanting this. 
	Compatibility (as far as it can get) before divergence.)



	An em was originally the width of an M (swashes don't count).

	In some typographic traditions an em is still the width of an M.

	In TeX an em is the width of an M.

	In CSS an em is the "font-size", and relatively few use it as yet.
		I haven't seen any good argument for keeping it "as is",
		other than an unwillingness to correct a mistake and/or
		to align with TeX. (Call it 'wem', or 'tem' if you like,
		but then deprecate the current 'em'.)  

		Correcting the definition of an em to what it 1) usually
		means (width of an M), and 2) what it means (width of an M)
		in *the* other *major* electronic typesetting context (TeX)
		should have little impact for most.  If someone asks for a
		line-height of 1em, then they should get what they ask for,
		a line height the same as the width of an M, nothing else.
		(Not a good thing to ask for, on the other hand. A
		line-height of 2 em might be more reasonable.  It's still
		easy to change line-height 1em to line-height 2em, or even
		better line-height 1line; see suggestion below.)

		See also my other parallel message on "font-size".

	In TrueType an em is undefined (it's up to each typeface designer
		what it "is").  This *so called* "em" should be left as
		something INTERNAL to a font, and should under not be
visible
		to anyone not doing font design work on that font.


So Erik, please revive your proposal (and, originally, my) to define
an em the same way in CSS as it is in TeX (which does pick it up from 
not only historical but also modern typography).  I still think it would
be a very bad idea to have the two most major electronic typesetting
contexts to have different definitions of "em".

See also MathML, which uses "em", but picks up certain special
width space names from TeX:


http://www.w3.org/TR/MathML2/chapter6.html:

&Space; 0020 one em of space in the current font 
&NonBreakingSpace; 00A0 space that is not a legal breakpoint 
&ZeroWidthSpace; 200B space of no width at all 
&VeryThinSpace; 200A space of width 1/18 em 
&ThinSpace; 2009 space of width 3/18 em 
&MediumSpace; 2005 space of width 4/18 em 
&ThickSpace; E897 space of width 5/18 em 
&NegativeVeryThinSpace; E898 space of width -1/18 em 
&NegativeThinSpace; E899 space of width -3/18 em 
&NegativeMediumSpace; E89A space of width -4/18 em 
&NegativeThickSpace; E89B space of width -5/18 em


This is one very obvious contact point between the TeX world
and the "Web/CSS world".  It is only confusing and non-productive
to define em in different ways among these two, let alone
(European??) typography, where an em is also still the width
of an M.


Note that this is not, and has never been, a suggestion
not to have some unit relating to the p-height
(p-height) or similar for other scripts.  If you don't
like the name p, then call it "line" (or whatever you like
better).  Text set with 'line-height 1.5line' would then
mean what is usually meant with having 1 and a half line
spacing.


		Kind regards
		(still trying to get this "spec.d/done right")
		/kent k
Received on Monday, 31 January 2000 12:22:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:03 GMT