I agree fully with this and would like to take it a bit further. Even
fully-sighted people may want to make the text on their screen larger than
imagined by the document creator. I often hear "how can you *read* that?"
when people are looking at my screen and I'm reading in 12-point type.
Further, not using ems forces the document creator to guess the width of
all the fonts as displayed on the viewer's screen. Fonts come and go, and
they've been known to change widths over time. There are whole industries
that have popped up around this unfortunate fact.
>One way around this (which would work for either separate units or the
>SGML Open suggested integrated units)would be for browsers to offer a
>magnification feature - 2x, 4x, 8x, 16x - and all units (except ems ;-)) would
>scale by this as would all text sizes. In that case it should be stated in the
>spec that sizes are rendering hints only and may be ignored or over-ridden
>by particular browsers.
Both ways of measuring column width have their advantages, but neither is
strong enough to have the other eliminated, IMHO. I support allowing both
with a discussion in the specs and so on about the advantages and
disadvantages of each. Personally, I would choose ems and then watch for
mixed font sizes; others would choose fixed sizes and hope (but not expect)
that viewer software will allow some sort of column expansion to fit larger
fonts than the creator expected.
(I vaguely remember one formatting language in the early '80s that allowed
you to specify table column widths as "wide enough to hold the phrase 'xxx'
in the font 'yyy'". Makes sense to me, but I also remember that the syntax
was impossible to describe easily.)
--Paul Hoffman
--Proper Publishing