- From: Felix Miata <mrmazda@earthlink.net>
- Date: Mon, 11 Jan 2010 04:12:38 -0500
- 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