RE: Clarify length units in CSS

Dave said:
>> The problem is with the pt unit.  Web pages use the pt unit without understanding that it is supposed to be an absolute unit.  They intermix it with pixel units >> and then the Web site's design breaks if you ever change that ratio.

My impression is that the misunderstanding is with the px unit, that *it* is treated as an absolute measure.

ROC said:
> In some future version of Gecko we might be able to relax the constraint that 1 CSS px is an integer number of device pixels. Our zoom implementation
> violates that constraint yet works surprisingly well, so the constraint doesn't seem to be as important as we originally assumed.

HP implements CSS px units as 1/96 inch. We tried the spec's suggestion to use ~128px/in (.2mm/px for printed output) and map to a whole number of device pixels, but found that existing web content designs rely on a px unit being 1/96 inch, so that approach isn't really interoperable. In our implementation, a px is then rounded to the nearest device pixel. (Our device resolutions are all 300 dpi and above.)

I don't believe we've seen any interoperability issues with the above approach. I understand this gets dicier when moving to screen resolutions of 143 dpi...  A programmable px unit could be helpful, but it wouldn't address existing content...

Best wishes,

Melinda

________________________________
From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of Robert O'Callahan
Sent: Wednesday, July 23, 2008 6:15 PM
To: David Hyatt
Cc: Tomas Carnecky; www-style@w3.org
Subject: Re: Clarify length units in CSS

On Thu, Jul 24, 2008 at 10:20 AM, David Hyatt <hyatt@apple.com<mailto:hyatt@apple.com>> wrote:

On Jul 22, 2008, at 4:02 PM, Tomas Carnecky wrote:

While I believe this is mostly what the spec intended (absolute units are indeed absolute, relative units relative), in some cases it will considerably differ. Let's say I'm sitting 28 inches from the screen. In that case 96px should be the length of one physical inch. It is indeed if I configure Gecko with DPI=N*96 (where N=1,2,3,...), but in all other cases 96px will be different from one inch. This is especially well visible in the case of DPI=143, when 1in is 50% larger then 96px (1in = 143 physical pixels, 96px = 96 physical pixels).

In some future version of Gecko we might be able to relax the constraint that 1 CSS px is an integer number of device pixels. Our zoom implementation violates that constraint yet works surprisingly well, so the constraint doesn't seem to be as important as we originally assumed.

WebKit on the other hand does not differ between CSS pixels and absolute units. Absolute units have a constant relation to CSS pixels. 1in is always exactly 96px, 1cm exactly 96/2.54px etc. This has the effect that 1in is only one physical inch long when DPI=96. Comments in the code indicate that this is intentional, WebKit doesn't see the 'absolute' lengths as absolute but relative to a CSS pixel [1]

So what is the correct interpretation of CSS lengths? Is Gecko or WebKit right or maybe both wrong?

The problem is with the pt unit.  Web pages use the pt unit without understanding that it is supposed to be an absolute unit.  They intermix it with pixel units and then the Web site's design breaks if you ever change that ratio.

This is true, but so far I've only seen one bug report that traced back to that issue. We're not experiencing any significant pressure to change our behaviour.

Rob
--
"He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]