- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 15 Feb 2012 13:28:09 -0800
- To: Lea Verou <leaverou@gmail.com>
- Cc: Sylvain Galineau <sylvaing@microsoft.com>, Boris Zbarsky <bzbarsky@mit.edu>, "www-style@w3.org" <www-style@w3.org>
On Wed, Feb 15, 2012 at 11:34 AM, Lea Verou <leaverou@gmail.com> wrote: > If I recall the css3-values prose correctly, a pixel is 1/96 of a CSS inch, > but a CSS inch is based on the assumption of a 96dpi resolution. So, it's > the inches/cm that CSS gets wrong, not the pixels. This is incorrect. The "d" in "dpi" is *not* a CSS px - it's a device pixel. The CSS px and in are linked in a 96:1 ratio, which happened because of legacy constraints caused by 96dpi screens being prevalent for so long, but that has nothing to do with the number that a browser can report for resolution. If a browser on a particular device maps 1 device pixel to 1 CSS px, then the resolution is guaranteed to be 96dpi. If they map 2x2 device pixels to 1 CSSpx, then the resolution is guaranteed to be 192dpi. Printers can have much more interesting resolutions (even ignoring the monochrome vs screening resolution issue). > If some devices use pixel ratios like 4 physical pixels for each CSS pixel, > it's exactly because CSS never provided a mechanism to define something with > physical dimensions. As a result, authors make designs that are based on > pixel lengths, and thus, would be way too small on high-dpi devices such as > iPhone 4. No, the CSS px was *meant* to have this behavior. It's supposed to represent a particular ocular angle, and we defined it to be the size of a legacy device pixel for convenience. ~TJ
Received on Wednesday, 15 February 2012 21:28:56 UTC