Re: Making pt a non-physical unit

On Wed, Jan 6, 2010 at 11:14 AM, Robert O'Callahan <robert@ocallahan.org> wrote:
> On Wed, Jan 6, 2010 at 10:52 PM, Giuseppe Bilotta
> <giuseppe.bilotta@gmail.com> wrote:
>>
>> Or we could fix Webkit and IE to do the right thing, and push for a
>> web that does the right thing.
>
> Please go ahead and persuade Webkit and IE people to change. Once you
> succeed, I promise Gecko will follow suit.

I'm in no position to make other UAs follow the specs (esp. not ones I
don't use), but if Gecko also decides to stop following it there's no
chance it'll ever be done. I'd rather see Gecko and Opera follow the
specs and Webkit and IE follow suit if and when they feel like it
(after all, even the IE people started feeling the pressure of
adhering to standard since Firefox and derivatives have gained a
significant market share).

>> If a fixed px/pt ratio is chosen as the preferred solution for the
>> mess of mixing absolute and relative units of measure, I would rather
>> see px defined in terms of pts (and thus of inches) as suggested
>> elsewhere in this thread, rather than the other way around, and have
>> the UAs query the display dpi to adjust for the physical px size.
>
> I explained previously why this is impossible.

I assume you're referring to user-defined DPI setting approach used by
Mac OS X and Windows.

My not-so-limited experience with a 133dpi monitor and Windows was
that setting the 'font DPI' to something else than 96 made almost
every single application break in one way or another (even for simple
UI elements like dialogs), so I would say that the problem there might
lie more in the o/s feature than in a specific app issue.
Additionally, in those case it's probably possible to consider how the
user setting compensates already for the different monitor DPI and act
accordingly.

By the way, the current CSS spec effectively suggests this approach.
The funny thing is that MSDN claims that even IE6 does it
http://msdn.microsoft.com/en-us/library/ms537625(VS.85).aspx

"""
Internet Explorer 6 and later solves these problems by proportionally
adjusting the scale on displays with higher resolution.

When scaling is activated on a 192 dpi system, for example, an HTML
element that has a specified height and width of 250 pixels has a
scaled height and width of approximately 500 pixels.

192 DPI / 96 DPI * 250 pixels = 500 pixels
"""

>> Rendering speed might suffer a hit on very low end hardware, but to my
>> knowledge this would only affect older hardware that is at 96dpi
>> already, i.e. not needing any 'conversion factor'.
>
> It's a measurable performance hit on any shipping browser on any hardware.

It may be measurable, but I would rather ask if and how it affects the
user experience. Navigating with a non-100% zoom factor in Opera for
me has no perceptible effect. My very limited experience with Safari
on an iPod touch showed me that changing zoom levels is an almost
constant experience for the user.

> Also, very few screens are actually 96dpi, even on "older hardware".

My current monitor is 99dpi in one direction and 98 in the other. The
old CRTs I still have lying around have a dpi of around 90, maybe
slightly less. Most of the monitors I stand in front daily are in a
similar situation. For these, 96 is a good enough approximation.

Aside: I used to have a hi-res (133dpi) monitor. And one of the things
that had me leave Windows and switch to Linux was precisely the fact
that Windows and most of its apps had abysmal support for this high
resolution. When someone at Debian had the brilliant idea to force the
dpi setting to 96 to 'fix' some apps, you can imagine how 'happy' I
was.

As higher-resolution displays become more common, proper support for
it becomes important. This it not fixed by imposing 96dpi on
everybody, and even standardizing this in something as important as
the CSS specification. This is fixed by fixing the broken
applications.

-- 
Giuseppe "Oblomov" Bilotta

Received on Wednesday, 6 January 2010 19:08:05 UTC