Re: Making pt a non-physical unit

On Sat, Jan 16, 2010 at 5:07 PM, Giuseppe Bilotta
<giuseppe.bilotta@gmail.com> wrote:
> On Sat, Jan 16, 2010 at 9:12 PM, Ambrose LI <ambrose.li@gmail.com> wrote:
>>> Consider also a long hallwall, with the walls covered in a wallpaper-like
>>> OLED. On one side, the display is from floor to ceiling, and the other side
>>> has some chairs and cabinets and so starts from 4 feet up to ceiling. I use
>>> DIVs and CSS animation and a little JavaScript to move infographics and art
>>> and advertising around as you walk down the hallway.  What does the display
>>> size tell you about the optimal viewing distance? Nothing. I might have
>>> smaller, detailed info at head level, and big arrows or background images at
>>> farther distances, way down there by those two doors at the end.
>>>
>>
>> 2010/1/16 Brad Kemper <brad.kemper@gmail.com>:
>> There is also the possibility that we (the designers) don't WANT
>> viewing distance to be considered. Say we design some app-like thing
>> to ultimately is going to be projected (or shown on large screen TV).
>> When we design and test the thing it's going to be viewed on regular
>> monitors, but we expect the final result to look identical to what we
>> see, only bigger. If viewing distance is going to have an effect on
>> sizes, it will become impossible to make these things.
>
> This is precisely why I wanted to give the designers the possibility
> to choose the 'expected' ratio between CSS and real units, some way to
> say "make 1px equal to one device pixel" vs "make 1in equal to one
> real world inch".
>
> (This could be pushed as far as allowing the designer to define new
> units, but this is most definitely out of scope for this discussion.)
>
> --
> Giuseppe "Oblomov" Bilotta

It seems like the unfortunate legacy here will be a bunch of units
with names that correspond to units in other media (e.g. a meter
stick) but have only a historical connection to them. While "pixel" is
certainly the correct nomenclature, "CSS pixel" already causes and
will continue to cause confusion in designers reading the specs.

Regardless, choosing a base unit and defining all other units in terms
of it seems like the only way to go. In a truly resolution-independent
world, as Tab notes, we can then only recommend a scaling factor for
types of media, in this case CSS pixel to an arc measure on screens
and inch to an inch in printing, as it is going to happen with a
standard or without.

But I think there is a strong argument to having access to a "device
pixel" (or "hairline," etc) as an *independent* system of measurement.
Certainly it can be a tool for users to shoot themselves in the foot
(e.g. font-size in device pixels), but even in a
resolution-independent world there are still effects where it is
advantageous to be able to specify values to the device pixel. The
example that's leaping out to me is that Canvas already exposes device
pixels through getImageData(). Forcing the user to rely on the UA to
algorithmically scale everything could lead to some terrible
aliasing/unintended effects in that case. The examples aren't
numerous, but there are an increasing number of per-(device-)pixel
effects being standardized these days (SVG filters, Canvas, gradients,
WebGL...) which would suffer if rasterized at the CSS pixel level
(and, indeed, their specifications usually recommend that the UA
rasterize at a higher resolution if they are being displayed that
way).

Of course, there is still a gotcha. On a high-dpi display, with a
(typically) fixed CSS-pixel to device-pixel ratio, having access to
the device pixel is advantageous and useful in the ways mentioned.
But, for example, on a mobile browser displaying a non-mobile page
that ratio is meaningless. There could certainly be a manufacturer
specified ratio and a well defined "zoom: 1", but in that situation,
really, the ratio is whatever the user of the browser decides is best
for the content they're viewing and is probably changing continuously.
But I'm sure there are people here that have thought about that
problem quite a bit (does mobile Safari expose zoom events?).

Received on Sunday, 17 January 2010 00:20:16 UTC