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

Re: Making pt a non-physical unit

From: Felix Miata <mrmazda@earthlink.net>
Date: Mon, 11 Jan 2010 04:12:38 -0500
Message-ID: <4B4AEB86.8020403@earthlink.net>
CC: www-style@w3.org
On 2010/01/11 05:38 (GMT) Alex Mogilevsky composed:

> ... what becomes problematic when dpi is different from 96.

Most Windows and Mac application developers, and most web designers, seem to
have embraced the notion that pixel perfection is a necessary element of design.

Typical application developers seem to think measurement only in pixels,
which have no fixed relationship to any physical size. All most know is to
fit text based upon the consequences of the default Windows/Mac 96 DPI
assumption. For Windows, that means UI (CSS2 "menu") text starts at a nominal
8pt, which is 11px @ 96 DPI. It's obvious few bother to test at any other DPI
(or with large or extra large fonts on the appearance tab of desktop
settings), because if they did, they'd learn that system fonts grow with DPI,
and outgrow the containers that they sized in px, which the text only fits
into as long as DPI is not increased. The few astute designers that exist
size font containers (including window & pane sizes) to grow along with the
fonts as DPI is increased, and may also do the same with related icons and
widgets. This intelligent latter sizing method amounts to designing in
resolution independence.

Most web designers using CSS have been doing pretty much the same as app
designers by sizing everything in px. Some in recent years have started to
embrace the notion that for accessibility reasons users should be allowed to
"resize" web page text. That meant, until IE started including its page zoom
feature, that IE users not using the accessibility option to "ignore font
sizes on webpages" would have to be given pages with text sized only with
keywords, %, or em instead of px (or pt, cm, in, mm, etc.). This tends to
work rather poorly, as with app designs the larger text constrained to space
designed for smaller text just doesn't fit well, at best creating less than
ideal words per line ratios, but more typically overflowing containers
(overlapping) or being clipped (disappearing).

Because IE default text sizing is DPI-dependent, unlike Safari & Firefox in
automatically growing with DPI, web page designs that size everything except
text in px are essentially inviting clipping and overlapping in IE that gets
worse before page zoom can even get into the picture. Even without leaving 96
DPI you can see this by using the old "View -> Text Size ->
smallest/smaller/medium/larger/largest" menu option (that can be placed
directly on the toolbar, and should be there by default
http://www.useit.com/alertbox/20020819.html ).

For both apps and web pages, containers can be sized in em. When they are,
and as long as the physical size of an em is kept reasonable in relation to
the physical size of the display, little to none of clipping and overlapping
occurs, regardless what physical size an em actually happens to be. These
designs won't be affected whether the proposal is implemented or not, since
they directly depend neither on the size of a px nor the size of a pt.
"Our Constitution was made only for a moral and religious
people. It is wholly inadequate to the government of any
other."                      John Adams, 2nd US President

 Team OS/2 ** Reg. Linux User #211409

Felix Miata  ***  http://fm.no-ip.com/
Received on Monday, 11 January 2010 09:12:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:42 UTC