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

RE: Units, font sizing, and zoom suggestion for CSS 3

From: Karlsson Kent - keka <keka@im.se>
Date: Mon, 17 Jan 2000 17:09:35 +0100
Message-ID: <C110A2268F8DD111AA1A00805F85E58DA68511@ntgbg1>
To: www-style@w3.org
> >         m - micrometer (spelling: use either U+03BC (preferred) or
> >                 U+00B5 as the first letter; the spelling with U+339B
> >                 should be deprecated, if at all allowed).

> Not useful - no property requires a unit that small.

Suggested to round off the set.  (TeX, e.g., has a smallest unit sp,
scaled point, which is about 3 nm (nanometers; there is a precise
definition of course).  One could argue that such a small unit is
"not needed", but TeX has it anyway, mostly because it is used internally.)

> >         dm - decimeter.
> Not useful - just use 10cm

Just to round off the set.

> > 
> >         pt - pica point, about 0.3515 mm (i.e. 351.5 m); should be
> >                 deprecated.
> The definition as 1/72 inch is fine. There is no need to change to
> metric.

A pica point has been, for many decades, 1/72.27 inch (i.e. about
351.5 m).  No need to change the metric!

> >         (bpt - big pica point, about 0.3528 mm (i.e. 352.8 
> m), 0.4 %
> >                 bigger than pt; should be deprecated, if at 
> all allowed.)
> See comments regarding extensions as being pointless - you can always
> use cm or inch if you really must.

This unit is included amongst the units that TeX supports, as
supplementary (it supports "true" pica points too, as well as
Didt points). The bpt is 1/72 of an inch (exactly).  But I agree,
this has been in use less than a decade, and differs very little
from the pica point. (I know, this is the point unit currently
specified by CSS.)

> > 
> >         dd - Didt point, 0.376 mm (i.e. 376 m), 7.0 % bigger than
> >                 pt, 6.6 % bigger than bpt; commonly used in 
> traditional
> >                 European (non-British) typography; new to 
> CSS but should
> >                 be deprecated.
> > 
> See comments regarding extensions as being pointless - you can always
> use cm or inch if you really must.

Pica points and Didt points should be treated in the same manner:
supported, but deprecated.

> >         pc - pica, about 4.2175 mm (i.e. 4 217. 5 m); 
> should be deprecated.
> The definition as 1/12 inch is fine. There is no need to change to
> metric.

A pica is *approximately* 1/6 of an inch (or more precisely:
4 217.5 m).  No need to change the metric!

> > 
> >         (bpc - big pica, 12 pt, about 4.233 mm (i.e. 4 233 m);
> >                 should be deprecated, if at all allowed.)
> See comments regarding extensions as being pointless - you can always
> use cm or inch if you really must.

The "big pica" (exactly 1/6 inch) has been in use for less than a
decade, and differs very little from the pica.  So I agree that there
is not much point in supporting it (hence the parenthesis above).
(I know, this is the pica currently specified by CSS.)

> >         cc - cicero, 12 dd, 4.512 mm (i.e. 4 512 m); 
> commonly used in
> >                 traditional European (non-British) 
> typography; new to CSS
> >                 but should be deprecated.
> > 
> See comments regarding extensions as being pointless - you can always
> use cm or inch if you really must.

Pica and cicero should be treated in the same manner: supported, but
deprecated.  The cicero unit has been in use for many decades.

> >         em - width(!) of a capital M in the current font and size;
> >                 this is the historically correct definition of em,
> >                 and the definition of em used by TeX; if there is no
> >                 M in the font, a suitable approximation is 
> calculated.
> This is a bad idea - it would ruin all old implementations. 
> My wem suggestion is backward-compatible

This is the proper, and traditional, definition of em.  If you for
compatibility reasons want to call it wem instead, fine. But then
one should strongly deprecate the old CSS em.

> > 
> >         (en - half an em. (Not necessarily the width of an N.))
> Superfluous, just divide your wems by 2.

Traditional unit, but of lesser value, I agree (hence the
parenthesis).

> >         tmu - 1/18 em, TeX 'math unit' (not so wisely called 'mu'
> >                 there).
> Superfluous; however less so as /18 is less easily done mentally.

Handy for fine tuning math expression layout.  Should be useful
for MathML.

> > Font size setting (font-ex-size is a suggested new attribute):
> > 
> >         font-size - sets (or changes) the p height, which is
> >                 maintained through typeface changes; the 
> ex, em, (en),
> >                 and tmu may vary depending on typeface.
> No changes to well-established properties please.

The current "font-size" leaves unspecified exactly which size is set.
But it is often something rather close to the p height.  My suggestion
is to make precise that it really is the p height that is set.
So this is not "change" but an "increase in specification precision".

> >         font-ex-size - sets (or changes) the ex height, which is
> >                 maintained through typeface changes; the 
> p, em, (en),
> >                 and tmu may vary depending on typeface; even though
> >                 the p height may change through typeface changes,
> >                 the baseline separation does not change with it.
> This I like very much.

Good.


> > Global zoom:
> CSS 2 specifies that zooming is left to UAs; I see no problem 
> with this.

The problem is that different systems uses in effect different 
global zooms.  The text that you did not quote was a suggestion
to make the default zoom value (for desktop/laptop screens) be given
by CSS (and adjustable by individual preferences) rather than be
OS or browser dependent.  Which IS a problem now!  (Yes, I know,
there are some upcoming 'hacks' (to IE5/MacOS) to circumvent that
problem, but it's rather inelegant.)


		Kind regards
		/kent k
Received on Monday, 17 January 2000 11:10:15 GMT

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