Re: Making pt a non-physical unit

On Jan 14, 2010, at 2:21 AM, Robert O'Callahan wrote:

> On Thu, Jan 14, 2010 at 2:02 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
> Our experience is that users do not expect the size of a CSS pixel to be different from one screen pixel by default. They do expect that content such as form controls will be displayed consistently inside the browser and outside it. Therefore attempts to automatically have CSS pixels approximate a particular subtended angle (which we have tried) are not appealing.

I find myself in complete agreement with you here, Robert (shocking, isn't it?). I know it is taboo to suggest that unzoomed CSS pixels should be based on device pixels, but I think it is the most reasonable thing to do, at least on non-print media, or at least on monitors (projection, handheld, or otherwise) where there is no reliable way to know the exact or average viewing distance (especially with things like movie theater screens, where there can be huge differences in viewing distance between front and back rows and between different theaters).

As an evil idiot author, I feel much of the value of high resolution monitors would be wasted if I cannot e.g. draw a border that is one device pixel in width while still maintaining the proportion between that 1px measure and other measures.

> Making CSS pixels different from screen pixels is something users should opt into,

I feel this already exists, via zoom controls. Indeed, this iPhone's high-rez display shows most Web pages in some sort of zoom level other than 1:1, without breaking the proportions between 1px and 1pt or other measures, and I think that works very well.

> preferably via a system-wide setting that affects the appearance of all applications (e.g., "UI scaling" on Mac). So the spec needs to permit such an approach.

I don't feel that strongly about that part. I think if the system knows that it is on a very high resolution device (300dpi+?), it can perhaps have some sort of "fit to window" mode or something that sets the default zoom level to something that creates fatter CSS pixels. But the user should still be able to zoom back down to 1:1. Hopefully the UI would also make the zoom controls more obvious as resolutions increase (on the iPhone they are both obvious and invisible, due to the well established convention there of pinching or double tapping).

> Also, I think we have use cases for true dimensions. We might as well ensure that 1px is 1/96 of an inch when printed, so that CSS absolute length units take their expected values when printing.

Right. Just as a device pixel is unambiguous on a monitor, but an inch is not, the situation is reversed in print. If I print to a PDF file, I can tell it to make something exactly one inch, but 1px has to be approximated (because device pixels are not too useful of a measure in high resolution printing; they vary too much between output devices).

> Exceptional circumstances like printing massive billboards would be ... excepted.

I disagree (ah, order is restored to the universe). If I create a PDF or Postscript file in which the design is 20 inches wide, then there is nothing exceptional about that. If I hand that file to a billboard company and tell them to print it at a ratio of one inch to one foot (or even if I do it myself by setting "1200%" in the print dialog box), then that is outside the purview of CSS. The scaling is more or less equivalent to zoom.

If I, on the other hand, design my layout to be 20 feet wide, then there still need be no exception, as long as the output device can handle rasterizing that many dots, and the print driver doesn't freak out. 

If I am designing a (different) billboard with a DIV that is 240in wide, and then set a border on it that is 1px wide (1/96in), then I will quickly discover what an idiot I am (and probably already did, long ago), because the border will not be visible from a car driving by. But if I design something that later is to be scaled by 24x, then I can make my DIV 10in wide with a 1px border, and get very predictable results when that pre-scaled (pre-zoomed) border is 1/96in.

For electronic billboards, we are back to the monitor situation, where no reliable assumptions can be made about how many pixels there are to a foot. I need to use percentages, or ems, or the billboard company has to tell me how many pixels wide to go.

> And for screen media I think we still have the use-cases of touch interfaces and "life size" diagrams which deserve a "true" unit.
> 
> Let me recapitulate...
> 
> How about the following definition for CSS pixel:
> For print media intended to be read "at hand", a CSS pixel should be rendered as 1/96 of an inch.

Agreed, but for all print media. 

> For all other media, including print media not intended to be read at hand, e.g., billboards, the user agent should size a CSS pixel so that it subtends a angle to the eye approximately equal to 1/96 of an inch at arms length; however, the user agent may take into account user-agent-specific constraints such as display technology, user preferences, and consistency with other applications on the same device.

I don't like that part. If I know that a scoreboard at the ball park is 800 pixels wide, with pixels the size of lightbulbs or whatever, I should be able to use that information to create borders that are one or two or three device pixels in width. It shares the same characteristics as other screen media.

> Then we can define the CSS absolute length units:
> 1in == 96px
> 1pt == 4/3px
> 1pc == 16px
> 1cm == 96/2.54px
> 1mm = 96/25.4px

That still works, because this is all pre-zooming, pre-scaling.

> Define "truemm":
> "truemm" is defined to correspond to physical millimeters in all media. For extremely small or large output surfaces, or when the physical media characteristics are unknown, the user agent may use an approximation.

I don't want two different kinds of mm.