Re: [CSSWG] Minutes and Resolutions 2010-01-27

On Feb 4, 2010, at 3:54 PM, CSS WG wrote:

> pts vs pixels
> -------------
> 
> [...]

> plinss: iphone zooming is just part of the normal way of dealing with
>          zooming in and out.
>  bradk: I'm not sure if the way the current zooming is ipmlemented,
>         if it's exactly the same as just setting how big a CSS px is,
>         or is there more to it than that?
>  bradk: But that's an impl detail, we can just recommend that there's
>         a way out of it.
> [...]

> szilles: What I think we're trying to solve is that px dimensions stay
>           commensurate with absolute units.
> [...]

>  szilles: I think we're getting confused by the media issue.  Perhaps the
>           issue of scaling/zooming, like Brad is talking about, is more
>           important.
>  szilles: I can see adding a property that defines mapping of px to physical
>           units, or somehow talks about being a zoomable surface.
>  szilles: I'm being vague, but I somehow think that fixing px to particular
>           number just is the wrong thing to do.  It's not capturing what
>           people are desiring.  So I'm agreeing with Håkon and Bert.

The number comes from trying to match it to what already exists, at least for the default, before any scaling.

I think it is not _actually_ necessarily mapping of px to physical units. It is more like mapping of px to CSS units that are named after physical units. This gives us consistency of proportion when the scaling/zooming any of the units. I see three cases where it matters:

1. In some cases (print, or monitors when the UA really believes what the OS tells it about the resolution), the CSS inch (or cm, etc.) will be considered the most trustworthy measure, and the CSS pixel will be scaled (possibly rounded to the nearest device pixel, but not always for every UA). 

2. Other times, the device pixel will be the most important because any belief in the accuracy of CSS inches to represent real-world inches has been thrown out the window. 

3. And in yet other cases, there will be no strong desire to match CSS inches to real-world inches, because the Web page is always being zoomed to whatever size is best for the user (as with mobile Safari, etc.). 

So by setting the ratio of CSS pixels to CSS inches, we get proportions that are maintained (to what they currently are most often, if we go with 96/inch). Then the CSS pixel can be zoomed/scaled and everything follows along. Or in print or super-high-resolution monitors, the inches get scaled to real-world inches, and the CSS pixel gets zoomed/scaled to remain in proportion to those inches.

Thus, there is some sort of scaling factor for the device-pixel/CSS-pixel in all cases, whether it is 1/1, or 2/1 (~200 ppi monitor maybe), or 1/2 (zoomed out to "half size" Web page), or 600/1 (600 dpi printer), or 1200/1 (600 dpi printer with page printed at 200% scale), etc. 

I had suggested a property that at one point I called "pixel-zoom" that would set this CSS pixel scaling-factor, but it could be just an implementation detail. I do think it is important for the user to have some sort of control over it, but browser UI is also an implementation detail. If there WAS as property though, then this would allow the user to use it in a user style sheet, even if the browser UI was somehow lacking for that task. But as I said in the call, this is not as essential as the rest of the above.