- From: L. David Baron <dbaron@dbaron.org>
- Date: Wed, 5 Oct 2011 10:55:47 -0700
- To: Brian Blakely <anewpage.media@gmail.com>
- Cc: www-style@w3.org
On Wednesday 2011-10-05 10:17 -0400, Brian Blakely wrote: > See spec for a refresh: http://www.w3.org/TR/css3-values/#absolute-lengths > > As far as I know, UAs have never actually implemented this, but always > pretended to anyway. If you size something as "1in", you're more than > likely going to get 90px, regardless of the accuracy of this output. 96px, but yes. Mozilla browsers used to do things differently: it tried to get the pixel density of the device, and used the *larger* of the real one or 96dpi (since assuming a value smaller than 96dpi frequently led to illegible fonts due to authors assuming that a 7pt or 8pt font would be legible, which it isn't due to rasterization at that size). (The 96dpi size comes from Windows, whose API for determining the pixel density of the display report results determined (at least in older versions of Windows) by a preference whose values are "Normal Fonts" (which means 96dpi), "Large Fonts" (which means 120dpi) and "Custom". This meant that the vast majority of Web users had displays detected as 96dpi, even when they were other sizes.) But this frequently led to Web-compatibility problems for users on devices correctly detected as having a pixel density greater than 96dpi, because Web authors tended to mix pixel and physical units however worked for them, often without understanding what the difference between a pixel and a point was, and in ways that assumed that 72pt == 96px. So Gecko switched to always mapping the existing physical units at 96dpi. See the posts Boris linked to in http://www.w3.org/mid/4E8C7F45.3010107@mit.edu . -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla http://www.mozilla.org/ 𝄂
Received on Wednesday, 5 October 2011 17:56:11 UTC