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

*We've discussed how your goal of finding out what kind of device is being
used is not well-served by option #2. What are your other use-cases?*

That was far from conclusive.  Without UA sniffing or developing an entirely
new technology, #2 is probably your best bet for delivering styles specific
to a device class. It is certainly better than the current arbitrary pixel
ratio, which is a disadvantageous circumstance to be in at all.

*If #3 is totally arbitrary at the whim of the device vendor, how can
authors use it at all?*

It is useful when authors would like to adapt a layout according to what
hardware vendors believe are the most appropriate and likely viewing
circumstances. You can consider this similar to using the default value of 1
REM for measurement, only with a deeper correspondence to physical space.

-Brian


On Thu, Oct 27, 2011 at 5:20 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Fri, Oct 28, 2011 at 4:55 AM, Brian Blakely <anewpage.media@gmail.com>wrote:
>
>> 3 means of defining an inch have have been discussed:
>>
>> 1. Pixel-ratio (almost always 96 px/in)
>>
>> 2. Actual (1 in/in)
>>
>> 3. Hardware Vendor Defined (X px/in)
>>
>> #1 is necessary for backwards compatibility, and it's also the current
>> status quo.  #2 serves a tremendous number of use cases,
>>
>
> We've discussed how your goal of finding out what kind of device is being
> used is not well-served by option #2. What are your other use-cases?
>
> and #3 offers some very interesting opportunities for adaptation.
>>
>
> If #3 is totally arbitrary at the whim of the device vendor, how can
> authors use it at all?
>
> Rob
> --
> "If we claim to be without sin, we deceive ourselves and the truth is not
> in us. If we confess our sins, he is faithful and just and will forgive us
> our sins and purify us from all unrighteousness. If we claim we have not
> sinned, we make him out to be a liar and his word is not in us." [1 John
> 1:8-10]
>

Received on Friday, 28 October 2011 15:11:27 UTC