On Jan 15, 2010, at 1:24 PM, Ambrose LI <ambrose.li@gmail.com> wrote: > 2010/1/15 Giuseppe Bilotta <giuseppe.bilotta@gmail.com> > On Fri, Jan 15, 2010 at 9:25 PM, Robert O'Callahan <robert@ocallahan.org > > wrote: > > On Sat, Jan 16, 2010 at 7:50 AM, David Singer <singer@apple.com> > wrote: > >> > >> a) on most screens a CSS pixel and a device pixel normally match > >> b) on most physical screens, actual lengths and CSS lengths (for > example, > >> inch) normally match; exceptions include at least the case where > there is > >> no physical surface at all (projection glasses) > >> c) there are 96 CSS pixels to the CSS inch. > > > > > > b) loses. > > Agreed, modulo setting in the UAs to choose a default zoom that > prefers b) over a). > > > I actually expect (b), though I know that (b) is not achievable > because even word processors and page layout programs can't do it > correctly. Sorry for the slow response (was traveling). I violently agree that (b) looses in screen, projection, etc. My experience is similar to Ambrose's, which is part of the reason I feel this way. The other part is the viewing distance thing for goggles, retinal imaging, movie screens, blimp screens, etc. I also agree with Giuseppe about zoom, but only if it is something that authors can set a value on to override the default, and relates to the zoom level controls in the browsers (that is, users can override). Probably should not be called 'zoom' though, since a lot of pages have 'zoom:1' to put IE into HasLayout, and the way I see it working is multiplicatively (if body has 'pixel-zoom:2' and a child element has 'pixel-zoom:3', then that child element has 6 device pixels per CSS pixel; browser zoom controls are actually setting 'pixel-zoom' on the root). For print you get a, b, and c, because (b) is a gimme.Received on Saturday, 16 January 2010 03:18:51 UTC
This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:42 UTC