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: Fri, 28 Oct 2011 09:09:11 +0100 (BST)
Message-ID: <1319789351.33331.YahooMailNeo@web28002.mail.ukl.yahoo.com>
To: "www-style@w3.org" <www-style@w3.org>
OK, you answered part of my question. I wasn't aware of the "~75 to ~150 
dpi" constraint implied by the definition of the "css pixel". It's basicly 
such a constraint that I was trying to achieve with my "min- and max-dpi" 
requirement. However, this leaves a still very eclesiastic landscape. That 
means that a same website can be twice as big on some devices. That's maybe 
a too big gap. My idea would be to allow the site developer to "force" the 
browser to choose a definition of the css pixel that match more closely the 
1/96idp. You could ask the browser to have a "CSS DPI" contained between 
threshold. That means that a CSS pixel could ends up to be a non-round 
number of physical pixels. But if it's what the developer asked. Currently, 
you can ask things like "initial-scale: 1" but you can't ask "set the zoom 
level to such a value that one css pixel is exactly 1/96 inch).

For 
the second part, maybe I wasn't as clear as I intended. I would 
introduce a 
"new kind" of DPI that is defined as "equivalent dot per inch if 
on a screen 
locate 0.5 meter away". That means that whatever the distance to 
your screen 
and his resolution may be, you have an unit that looks 
"familiar" to the 
developper and that it's simpler to use than an "angular 
unit".

François


----- Mail original -----
De : Boris Zbarsky <bzbarsky@MIT.EDU>
À : www-style@w3.org
Cc : 
Envoyé le : Jeudi 27 Octobre 2011 21h01
Objet : Re: User Agents Do Not Implement Absolute Length Units, Places Responsive   Design in Jeopardy

On 10/27/11 2:34 PM, François REMY wrote:
> 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 ?

Good question.

> Can it be 1/120ipd? Can it be 1/180ipd?

The spec says:

For such devices it is recommended that the pixel unit refer to the
whole number of device pixels that best approximates the reference
pixel.

which means that the answer depends on the size of the device pixels.
It's also not a hard requirement.  But clearly, if this requirement is
followed then 1/180ipd can't happen, because you'd just double your CSS
pixel size and use 1/90ipd.... assuming the viewing distance is arms-length.

> 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.

I'm not sure what you mean here...

> Could it be possible for a website to specify a "target resolution"?

In what sense?

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

"dpi" is a somewhat meaningless metric unless you know the viewing
distance, no?  If not, what would be the use case?

> 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).

I'm not sure what use case you're trying to address.  Could you explain
that?

> 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.

That's the general idea, yes.

> 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's what the current spec tries to do, within the level of
capabilities of the device.

-Boris
Received on Friday, 28 October 2011 08:09:40 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:45 GMT