Re: Hey Microsoft! cool it with CSS points ok?

Eric A. Meyer wrote, at 10:08 -0500 on 24.11.97:

> > Before
> > anybody's eyes glaze over, have a look at the Microsoft corporate home
>page
> > in Microsoft's browser for Macintosh, IE3 or 4:
> > http://www.verso.com/agitprop/points/font_wars.GIF (43K).
>
>    I didn't see what you saw.  Here's what I got instead:
>      http://www.cwru.edu/dms/homes/eam3/css1/msie.gif (49K)
>
>    The weird not-quite-dithering you'll see are an artifact of the image
> conversoin to GIF, and didn't appear on the actual Web page.  Note the
> address, though:  I was shunted to an Active Server Page which is
> (apparently) supposed to be tuned for IE4.0, even though it wasn't quite
>so.
>    I'd like to point out that the four links near the top of the page--
>the
> ones with the arrows next to them-- are specified in the source as being
> 8-point Verdana, not the 7-point text Todd saw in his version of the
> Microsoft homepage.  (Don't get me started on the philosophical
> implications of this.)  In other words, both sets of text look the same,
> but the source says they aren't.  Erk.

On Macs without anti-aliasing, pretty much all normal (u&l-case roman) type
is illegible below 9pt, because on Macs, 1 point is 1 pixel (type is
rasterized to a nominal 72dpi, regardless of actual physical pixel
density). Why do you need at least 9 points/pixels? Count the vertical
"pixels" necessary to represent the essential features of these
"minimalist" ascii letters (Eg):

1
2
3	####
4	#
5	###   ###
6	#    #  #
7	####  ###
8	        #
9	      ##

You need the two on top to keep contiguous lines from colliding, and to
permit accented caps. You can't represent these characters with fewer
pixels without violence to the basic letterforms. This also shows how point
size for a font is larger than the actual measure of any character in that
font - the "E" above is just 5 pixels/points high, right? Yet this is a 9
pixel/point font.

> >The danger of specifying point units in CSS is compounded by their use
>with
> >special fonts, whose legibility characteristics at any nominal point size
> >are better than average, like "big looking" Verdana (and most of the
>other
> >very fine free MS Core Web Fonts).
>
>    Okay, I'm not a font expert, so maybe I'm a little confused.  I had
> thought that points measured distance, as in 1/72 of an inch.  Is this so?

Yes. Sort of. It doesn't matter. :^)

> If not, is it supposed to be so?  Because I can understand not using
>pixels
> to specify font size, given the wide range of monitor resolutions, but I
> had been assuming that points were a good, generic solution for the
>problem
> of creating legible pages that were pretty much resolution-independent.

This is the case for Web pages that are being sent to printers with
resolution-independence features. Printers know how big their dots are, and
can adjust the count of dots to print a 1" line accurately, whether it's a
300 dpi or a 1200-dpi printer. Their dots are generally small enough that
you can keep out of trouble with even the smallest common type sizes,
though a 1200-dpi printer is capable of printing text you can read only
with a magnifying glass, while a 300-dpi printer with the same challenge
will produce only a microscopic row of toner dots.

With computer display systems, all of this goes out the window. The OS
doesn't generally know how big the dots on the monitor are - there are all
these analog controls and messy physics intervening - and anyway who cares?
People don't read from screens with the same ease and varying distance for
magnification as from paper. So the OS takes a guess.

With the Mac it guesses that the dots are 1/72 inch, which is convenient
because typographical points are that size. So when you ask a Mac to show
you 9-point type, it allocates 9 pixels (vertically), and fills in the dots
as best it can. Tell it to show you smaller, and you get the MS effect:
mud. Note that the mud is not necessarily too small in a literal physical
sense - at 72 dpi, it's accurate, but the dots themselves are too coarse.
This is why it doesn't matter whether or not the display is representing
the physical measures (points) accurately on screen.

With Windows, the OS guesses that screen dots are smaller: 1/96 inch. Or
maybe 1/120 inch ("large fonts"). Relative to the Mac, this means that the
system allocates 33% more dots per glyph at any given point size. And this
is the root of our troubles: Windows authors make guesses about the
legibility of point-specified text based on how many pixels it occupies on
*their* screens - NOT how big it is (as in "pull out the calipers and
measure"). If it's the pixel-patterns they're after, they should specify
pixels (but there's a better way still).

Now, you may be saying: sounds like Windows is better in this regard.
Hogwash. Both systems are inaccurate in their representation of real
physical measures when the actual display resolution varies from either 72
or 96 dpi. Actually, many Windows systems (with Matrox video drivers) let
users customize the resolution of their systems: to 72 dpi, 150 dpi - you
name it. I don't mean changing from, say, 800x600 to 1600x1200. I mean
changing the number of dots per inch the system will assume when asked to
render physical measures like points or inches. If you visit the MS
homepage with your display system set to rasterize type at 150 dpi, all the
pixel-specified artwork would shrink pathetically alongside the huge
type.... So maybe Windows does have an edge here, but specifying type in
points for screen display is just as silly as ever.

Unless you specify all screen graphics in the same unit system: not in
pixels.

>    Given that this is not, apparently, the case, what is left to us poor
> Web authors?  Todd continues...
>
> >More to the point, these sizing issues would go away if CSS authors (and
> >their corporate sponsors) would make it a policy not to use point or
>pixel
> >units for type in Web pages. These units render inconsistently, so any
> >illusion of greater control is, well, illusory, and finally unfriendly.
> >[...zap...]
> >CSS allows author/designers to specify the size of fonts and other
>objects
> >like graphics in units or expressions that can be relative to user
> >preference or need: these units are em, ex, %, and "larger" or
> >"smaller".
>
>    These are all, I agree, methods of dealing with the issue.  However,
> they're still a little short of the mark at which Microsoft et.al. are
> aiming, and here's why.

What's that mark? Something you could do with a big GIF? A PDF? Leave out
the nonvisual considerations: what's the vision for the visual behavior of
the page?

>    Let's say I want to create a sidebar of links in which the text is
>small
> enough to minimize canvas usage, but large enough to be read.  I can
>define
> this text as being "font-size: 66%;", and if the reader has his default
> display set to a font size which makes this text too small, then raising
> that size will make the sidebar more legible....and make the main-body
>text
> much larger, possibly badly upsetting the balance of the page.

What do you mean when you say "the balance of the page"? I suspect you mean
"the type areas will get out of synch with the graphics, losing alignment,
appropriate relative masses, etc." The disconnect occurs because not all
elements' sizes are specified in the same unit system. The graphics are in
pixels and the type in points (or ems or whatever). This is a pretty simple
recipe for imbalance. More importantly, because neither of these units are
susceptible to inheritance, there's no communication among elements in the
document's rendering tree. It's a dead tree, and it falls over when you
push it.

If your page is like a nice orderly cemetery, moving some of the headstones
around or inflating them really can upset the balance of the space. But if
your page is like a basketball court, things get out of balance if the
elements *don't* all respond to the movements, expansions, and contractions
of their peers. I'm not talking about gratuitous typographical animation,
but about essential typographical adaptation to the constraints of the
rendering environment and the needs of the user. It's about porting visual
design intelligence into runtime, out of "design time."

There's such a rich set of possibilities for dynamic design with CSS, and
maybe a little scripting to help in a pinch. (I'd like to make line height
a function of column width and the ratio of ex to em of the face in use,
and column width in turn a function of window width, but with an upper
constraint of 36em....) Today's implementations have enough gotchas to make
this a fairly academic reverie, but hey somebody's gotta do it.

CSS2 is great, but a lot of this would be possible if there were any CSS1
implementations. You know what happens if there are bubbles in your clay
when you fire the glaze....

_________________________________________________________________
Todd Fahrner                             mailto:fahrner@pobox.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 Monday, 24 November 1997 12:33:50 UTC