Re: font-size Progress

Susan Lesch wrote (2:49 PM -0500 1/13/98):
" Does anyone have a guess why on screen, in MSIE 4.0 Mac, pt, pc,
" in, cm, and mm display relative to the user setting? Also, smaller
" and larger are absolute sizes, as these two were in 3.01a, except
" now larger is 14 point. Maybe most interesting in IE4-Mac, when
" set in BODY, 1em, 100%, and medium are 14 point, up two points from
" 3.01a. Apparently this work is partly finished. Maybe it indicates
" a chance for a 12 point base font-size in coming versions of IE?

Thanks for bringing this up, Susan. It feels like I'm usually the one to moan about this stuff, so I try to hold back to keep from getting lost in my own noise.

Yes, it is extremely annoying that MacIE4 implements the diametric opposite of the behavior discussed here recently as correct[1]: absolute measures are adjustable through the UI, while relative measures like em cannot be overridden!

You're looking for guesses about why it's this way? Here are some, in increasing order of cynicism:

1. These sorts of oversights are perfectly natural for beta software. Beta software, by definition, is that which introduces previously unimplemented features, yet which remains to be tested rigorously. Everybody knows that PR1 was an entirely different piece of software WRT to CSS and DOM. I believe this is the first browser release since 1994 not to have been tested publically before being deemed "final." Public testing isn't always the same as "rigorous", but MacIE4's private test loop was obviously too tight and too loose at the same time.

2. The MacIE4 team was operating under absurd time and resource constraints to squeeze something out in time for MacWorld, even as PR1 had been Frankensteined from 3.01a just in time for the last MacWorld. I predict that the next MacWorld will feature an IE5 "preview" release claiming support for XML and XSL, but which will really be MacIE4 with about 4% new/different code soldered on, half of which will be purely cosmetic.

3. Through intensive research, MS discovered that Macs render type at 1 pixel per point. This makes many pages styled in Windows with CSS point units illegible in Macs [2]. Rather than encourage people to use non-absolute units for screen work per the CSS1 Recommendation [3], they decided to make points and other absolute units meaninglessly mutable on the Mac. For a perverse symmetry's sake, they decided also to make relative units absolute. After installing MacIE4, I'm surprised my pointer still moves left when I move the mouse left. You've heard the joke about how many MS people it takes to change a lightbulb? None: they declare darkness the standard.

4. MS hopes to make the confusion and dismay in the CSS authoring community complete, the better to render Netscape's CSS catch-up efforts meaningless, and the better to prepare the market for the shiny new XSL/XML[4] model, which, unlike CSS/HTML, will have been driven by MS nearly from the beginning, and which, unlike CSS, will be free from the forbidding stench of massively deployed misimplementations. That's when Win00 and Office00 will become the only really effective points of access to Web viewing and authoring, respectively, and the experiment will be over.

 * * *

Maybe the Mac can no longer be considered a major platform - certainly our numbers aren't keeping pace with the growth of the industry. Those of us left, though, tend to be in communications design. In fact, I've seen at least 3 or 4 claims in trade press over the last year that more than 60% of professionally-produced websites are created entirely or in part on Macs. And just about every single site ever to win a design award by "design industry" press (ID, Communication Arts, Eye, etc.) was made entirely on Macs. Of all the people who might notice and care passionately about the integrity of a CSS implementation, I'll bet an absolute majority are Mac users. This release hurts.

The chickens are starting to come home: http://www.hotwired.com/webmonkey/98/02/index0a.html?tw=eg




[1] David Perrell, Todd Fahrner, and Hakon Lie, respectively:

 > " I thought it was established that the UA has
 > " a hypothetical default stylesheet and that changing the default font in the
 > " UA changes the base font size in that stylesheet. Therefore, changing the
 > " font on the toolbar should change the font size in any element for which
 > " font size has not been specified either in absolute units or relative to an
 > " ancestor element specified in absolute units. Conversely, elements declared
 > " in author stylesheets in absolute units should be unaffected by UA font size
 > " changes.
 > 
 > This is precisely as I see it, also. Thanks for the nice
 > articulation, David. What I'd really like to know is whether there's
 > any dissent on this point (especially among implementors).

There is no disagreement on the goal, I believe.


[2] http://www.verso.com/agitprop/points/font_wars.GIF

[3] http://www.w3.org/TR/REC-CSS1-961217#length-units

[4] http://www.microsoft.com/xml/xsl/XMLViewerDemo/XMLViewer.htm - very slick, but have a look at the xsl stylesheets themselves, e.g.: http://www.microsoft.com/xml/xsl/XMLViewerDemo/summary.xsl They're basically HTML tables with data slots in 'em ferchrissake! I dearly hope XSL will mean not just data transformation capabilities, but a refinement and expansion of the basic display types/flow objects we've got today. Tables for layout of nontabular material, especially, are a hack I'd expect even a proper CSS implementation to retire - much more so XSL.


Todd Fahrner
mailto:fahrner@pobox.com
http://www.verso.com/agitprop/

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 Tuesday, 13 January 1998 22:43:55 UTC