W3C home > Mailing lists > Public > www-style@w3.org > October 2011

Re: User Agents Do Not Implement Absolute Length Units, Places Responsive Design in Jeopardy

From: François REMY <fremycompany_pub@yahoo.fr>
Date: Thu, 27 Oct 2011 20:34:55 +0200
Message-ID: <ADE68548A38B46F89612AAC73E8D2CF0@FREMY2>
To: "Brad Kemper" <brad.kemper@gmail.com>, "CSS 3 W3C Group" <www-style@w3.org>
OK, I accept your argument. In fact, you just have transformed the problem
from "we need to have physical units" to "let's make the pixel unit virtual
to match a physical range". But then, how well must a "px" match 1/96 inch
per dot ? Can it be 1/120ipd? Can it be 1/180ipd? I'm ready to accept that
the size of a screen can remain unknown in the detail, but you should always
have an order of magnitude available to help your adapt your layout.

Could it be possible for a website to specify a "target resolution"? At this
time, we can only ask for a "zoom" level (ie: how much does a "px" unit
translate in physical pixels). The problem is that this data is linked to
the DPI resolution and not to the site "per se". Maybe a great resolution
would be something like that :

    <meta name="viewport" value="min-dpi: 80, max-dpi:120" />

If the device's (approximative) dpi is in the desired range, the site is
shown unzoomed. But if it doesn't fit the range, the zoom is computed to
match as closely as possible the median value between the minimal and
maximal dpi value (a physical snapping could be used to round translations
like 1px -> 1.85physPixel to 1px -> 2physPixel).

Even if there's a certain range of DPI I'm needing to care about instead of
one, I can deal whit the fact an inch is a little bigger or smaller than one
inch. But at least, I can test my website on a range of device and see it
works well on those devices. But if a new "strange" device appear, it should
do fine (or at least as fine as it is possible) because it tries to
"emulate" the kind of devices I tested my website on.

As a side note, the "dpi" I'm talking about is not especially the "true"
device DPI, but the perceived DPI of the user. This need the screen vendor
need to provide that info, halas. If it doesn't, the browser will have to
guess that based on the general usages of the device.

To summarize, what I propose is to accept the fact there's an uncertainty
but limit that uncertainty to an acceptable level to the developer. That
level can vary from developer to developer depending on the time he has to
adapt his layout to more different DPI's and screen resolution.

-----Message d'origine----- 
From: Brad Kemper
Sent: Thursday, October 27, 2011 12:02 AM
To: François REMY
Cc: Boris Zbarsky ; Brian Blakely ; <www-style@w3.org>
Subject: Re: User Agents Do Not Implement Absolute Length Units, Places
Responsive Design in Jeopardy

On Oct 26, 2011, at 2:45 PM, François REMY <fremycompany_pub@yahoo.fr>

> Are you basicly saying that since no solution is perfect we should have no
> solution to the problem at all?
> To me, it seems like the physical size of a device is (nearly) sufficient
> enough to adapt your design (Input/Output methods available should be
> taken in consideration too). If you want to challenge that idea, feel
> free, but come up with cases where having physical measurements of the
> device is a bad thing or don't help to solve a layout choice problem.

One JumboTron-like display is 640x480 (using lightbulbs), and another is
1600x1200 (using LEDs). If you want to display a Web page on both, using
media queries on pixels is going to be much more useful than knowing their
physical size. Same thing for projectors, where the actual physical pixels
might be on something the size of a postage stamp (or smaller), but it is
often unknowable how far away the screen is (and thus how big the final
projection is on that screen). What happens in these cases when you write a
media query for your Web page about the physical size?

We've had these discussions before, ad nausium, and we resolved on them. = 
Received on Thursday, 27 October 2011 18:35:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:06 UTC