W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > April to June 2014

Re: pixel densities, text sizing

From: Felix Miata <mrmazda@earthlink.net>
Date: Thu, 08 May 2014 02:50:29 -0400
Message-ID: <536B2935.8020504@earthlink.net>
To: w3c-wai-ig@w3.org
On 2014-05-03 02:06 (GMT+0100) Patrick H. Lauke composed:

> Well, as we're talking retina versus non-retina...have a look at this shot

Actually we weren't. The mention of Retina was an offer of proof of a real 220DPI 
device people could buy and use as opposed to some arbitrary "non-standard setup".

> http://i.imgur.com/q76abmy.jpg

And if I had selected the non-Mac 235 DPI M3800 Dell instead?....

> MacBook Pro with Retina display on the left, MacBook Pro with non-Retina
> on the right. At same viewing distance all the text looks exactly the
> same size...because the OS compensates for the higher pixel density. So
> your example screenshots don't actually reflect the reality in this
> particular case.

My screenshots don't purport to address any ability or not of any DE to in any manner 
vary the physical size of a CSS px to match or emulate some specification. That's a 
whole other subject orthogonal to the reasons why I wrote and write in this thread.

I write because using the px unit, among other things:

1-for setting text size wholly and utterly disregards user-determined optimal text 
size as registered by the visitor's UA default size. Translation: disrespect for 
users (aka rude); negative accessibility impact.

2-for setting container size and/or leading can cause an assortment of problems when 
text size is forced by the user to deviate from the stylist's CSS "suggestion" toward 
or reaching user-optimal, including but not limited to: hidden text, overlapping 
text, uncomfortably or inanely short line lengths, and misinterpretation due to 
unexpected text position.

3-is absolutely unnecessary to effectuate the perspectives inherent in any particular 
web page design, unnecessarily reducing accessibility

> In fact, this is consistent with the reference px definition: at the
> same viewing distance, the CSS reference pixel dimension needs to remain
> the same, regardless of actual physical device pixels. If I follow the
> rationale of your viewing instructions, you seem to imply that a viewer
> should adapt their viewing distance in order to keep the ratio of the
> dimension of a *physical* pixel and the viewing distance constant,
> whereas the CSS px reference definition is based on the ratio of the
> dimension of a *CSS* pixel and the viewing distance. For the same
> type/class of device, with same screen size, I should not adjust my
> viewing distance at all...it's the OS that needs to adjust its mapping
> of CSS pixels to physical pixels.

[Addressed by my 2014-05-08 01:11 (GMT-0400) thread post.]

>> Have you never noticed that as the price of PC
>> equipment goes up, that pixel density, on average, goes up too, meaning
>> everything shrinks

> No it doesn't, see above.

You missed the part about "on average". A Macbook Pro is anything but average. An OS 
or DE may or may not provide a reasonable compensation, if any at all, for display 
pixel densities that deviate modestly or moderately from the standard 96 assumption. 
e.g. on Windows 8 DPI must reach 140 in order for it to scale, and to scale further 
180 must be reached.

....On the 235DPI M3800 Dell, according to that blog URL, Windows would be applying 
180DPI scaling to a 235DPI device, a 23.4% nominal shortfall, a 41.3% shortfall WRT 
real size (a function of squares, it takes only a 41.4% increase in height and width 
to produce twice the px in total. A 1920x1200 screen's px count is 12.5% greater than 
a doubling of the px count of a 1280x800 screen. An em block twice the physical 
*size* of a 16px em block if it could exist would be 22.6275px.).
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
Received on Thursday, 8 May 2014 06:50:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 October 2015 16:21:51 UTC