RE: [CSS21] Issue 149 - px vs. pt

I think the "use case issue" is a red-herring. That is, I think the use cases are clear.

Use case 1 for "viewport different in size from its physical dimensions": there is a vast collection of existing webpages that have been "optimized" (read: only really display on) a desk top (or laptop) screen. Makers of devices with other form factors (whether smaller as in phones or larger as in TVs) want to display these pages on their device.

Use case 2 for "viewport has size of its physical dimensions": Content providers recognize that the zooming and scrolling experience is not very pleasant for users and would like to be able to design pages that better match the physical size of the device. For this, media queries should work.

I believe that as the use of Media Queries (MQs) in style sheet becomes more popular, the number of pages developed by use case 1 authors will decline, but it will not go away! 

We (none of us) are able to legislate that one of these "camps" should go away. It seems from the discussion, that the best we can do is tell each camp (of authors) how to best achieve their desired result: using a large canvas that is zoomed and scrolled for use case 1 above and using a canvas that matches the device size for use case 2 above.

As has been noted in this discussion, satisfying use case 2 means that an author must be able to query for the physical size of the device. I personally think that means asking in "absolute units" (per the CSS usage of the term) not in "pixels" (physical or CSS). It has been noted, however, that devices are currently lying about this type of query. If, indeed, the cat is already out of the bag, then we are being driven toward providing a new way to ask the physical size question. 

I am not fond of the "truemm" proposal because I think there are too many unit types already and this, in principle, would lead to even more. I do not,however, have a better suggestion at this time. The kind of thing that would make sense to me would be a way to specify whether a given MQ was to be interpreted as a physical query or a non-physical query (i.e. one that can be lied to). This would hold for any MQ (or any MQ on dimensions). I do not have a syntax proposal for this.

Steve Zilles


> -----Original Message-----
> From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf
> Of Sylvain Galineau
> Sent: Thursday, July 01, 2010 12:26 PM
> To: tantek@cs.stanford.edu; David Singer; www-style@w3.org list
> Subject: RE: [CSS21] Issue 149 - px vs. pt
> 
> Agree with Tantek and David on this.
> 
> Following at least two face-to-face discussions on the topic that both
> agreed to resolve the issue
> by making the px 1/96" 96px/inch, I thought I understood the issue. I'm no
> longer sure I do :( Nor
> do I understand the basis on which it is being changed in terms of either
> use-cases or the issues
> addressed by the new proposal. I'm sure Mozilla has very good reasons to
> want this for phone UI
> but if so they deserve elaboration, as any relevant use-case does.
> 
> -----Original Message-----
> From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf
> Of Tantek Celik
> Sent: Wednesday, June 30, 2010 9:10 AM
> To: David Singer; www-style-request@w3.org; www-style@w3.org list
> Subject: Re: [CSS21] Issue 149 - px vs. pt
> 
> As someone who ha had considerable experience in both dealing with these
> issues and a reasonably thorough/robust a related implementation in the
> past (IE5/Mac with adjustable DPI preference, 96ppi default), I am having
> difficulty understanding how to evaluate the different options for this
> issue.
> 
> I believe David Singer has hit upon the most important point in this
> thread:
> 
> > Overall, I think we need some examples of problems that require that
> > we know any or all of
> a) the true physical dimensions of the actual viewing surface (which may be
> a logical surface over which the physical screen pans)
> b) the true dpi of it (using true dots and true inches)
> c) the true physical dimensions of the screen itself
> 
> I agree 100%
> 
> I'd like to see those who want to change CSS here provide real world use-
> case examples of a,b,c on the wiki and cite/reason with those to make their
> case.
> 
> Thanks,
> 
> Tantek
> 
> 
> -----Original Message-----
> From: David Singer <singer@apple.com>
> Sender: www-style-request@w3.org
> Date: Wed, 30 Jun 2010 07:54:06
> To: www-style@w3.org list<www-style@w3.org>
> Subject: Re: [CSS21] Issue 149 - px vs. pt
> 
> Stephen
> 
> I think that there are (alas) now several possibilities on the table:
> 
> a) the one Elika already posted;  that has all the physical units in their
> normal relationships (inch, cm, pt) and also has 96 px/in (which we have
> learned is assumed and necessary, unfortunately);  that proposal asks
> displays to choose whether they match physical units at their display
> surface, or whether they instead match a reasonable definition of the angle
> subtended at the eye by a reference CSS pixel.  For print etc., the first
> is usually more applicable;  for devices viewed at 'unusual' distances
> (high-res handhelds, billboards) or devices without a display surface at
> all (e.g. projection eye-glasses), the second.  In both cases, we respect
> the definitions of the physical units and their relationships;  but in the
> second, that relationship holds at a distance other than that that the
> image is at.
> 
> b) make px, pt, pc etc. be in one group of units, and in, cm, mm etc. in
> another.  The second group would 'always' match physical reality, and the
> first would match the reference pixel.  This means, as you say, that there
> might not be 72 pts to the inch.
> 
> c) try again to maintain that pt, in, cm, etc. have their well-defined
> relationships, match physical reality, and screen dpi may and does vary.
> 
> I don't think (c) is seriously proposed, as we sort-of tried that and
> failed.  I don't think it works either;  if I design a page to display at
> 8x10in and someone puts it on a billboard, I really don't think it should
> occupy a space of 4x5px in a tiny top-left corner, for example.  Nor do I
> think that hand-held devices should be stopped from showing it on a viewing
> area that is 4x5in, with the ability to scroll around to see all the
> pixels.
> 
> If we have had trouble maintaining that dpi was variable, I have a hard
> time imagining we can handle having pts-per-inch as variable, which is what
> I think Elika is suggesting in (b).
> 
> I don't think (a) redefines mm;  that's somewhat of a strawman.  It allows
> the logical viewing surface on which it is measured, and related to other
> units consistently, to be at a distance other than the physical surface (if
> there is one).
> 
> I think that XSL-FO has not encountered the usage that CSS has had, and
> hence has not had to struggle with the 'assume 96dpi' problem.
> 
> Overall, I think we need some examples of problems that require that we
> know any or all of
> a) the true physical dimensions of the actual viewing surface (which may be
> a logical surface over which the physical screen pans)
> b) the true dpi of it (using true dots and true inches)
> c) the true physical dimensions of the screen itself
> 
> On Jun 29, 2010, at 18:12 , Stephen Zilles wrote:
> 
> >> -----Original Message-----
> >> From: www-style-request@w3.org [mailto:www-style-request@w3.org] On
> >> Behalf Of fantasai
> >> Sent: Tuesday, June 29, 2010 3:13 PM
> >> To: www-style@w3.org
> >> Subject: Re: [CSS21] Issue 149 - px vs. pt
> >>
> >> On 06/16/2010 06:32 PM, fantasai wrote:
> >>> I was given an action item to write proposed wording for CSS2.1
> >>> Issue 149
> >>> http://wiki.csswg.org/spec/css2.1#issue-149
> >>> to define a fixed ratio of 4:3 for pt:px and to allow the physical
> >>> value of these units to vary. Since it's a multimedia section and a
> >>> complicated set of changes, I've posted the wording as HTML here:
> >>> http://fantasai.inkedblade.net/style/specs/css2.1/px-unit
> >>
> >> I've been thinking about this issue, and I've come to the conclusion
> >> that, roc's original proposal to redefine points (and picas) but not
> >> the other units makes more sense. Here are the arguments that have
> convinced me:
> >>
> >>   - We do have use cases for real, physical units. Mozilla's team,
> >>     for example, wants them for its mobile phone UIs.
> >>   - Defining mm, cm, and in relative to px has rather unexpected
> >>     effects on Media Queries: I can no longer query the physical
> >>     dimensions of my screen or viewport, only its pixel grid size.
> >>   - The point, as a unit, has only very recently been standardized
> >>     and already suffers from multiple definitions:
> >>       http://en.wikipedia.org/wiki/Point_%28typography%29
> >>
> >> So here's an alternate proposal
> >>   http://fantasai.inkedblade.net/style/specs/css2.1/pt-unit
> >> that defines two groups of units:
> >>   * px, pt, and pc as device-relative (based on CSS px)
> >>   * in, mm, cm as physically-absolute
> >>
> >> The two map together when either
> >>   a) we're printing, in which case CSS points map to PostScript points
> or
> >>   b) effective device resolution is unknown, in which case an inch maps
> >>      to 96px
> >>
> >> This addresses the use cases for real physical units, addresses the
> >> web-compat problem with authors mixing points and pixels, and avoids
> >> redefining the millimetre. Given that roc suspects it won't break the
> >> Web, I'd rather go this route.
> >>
> >> ~fantasai
> >
> > The point, "pt" is just one of the absolute units that have been long
> defined in CSS2 and have been used in other specs, such as SVG. The
> relationships defined between the absolute units have existed for longer
> than even CSS has existed and breaking that relationship would need
> analysis of more than just CSS files. In particular, SVG files are likely
> to use inches or centimeters for the graphic parts of a drawing and points
> for the textual labels. If these no longer matched there would be
> significant complaints.
> >
> > But, I think that there is a better way to approach the screen size
> problem. At a previous CSS F2F, we agreed that when printed, points are
> points, inches are inches, etc. What I propose is that we treat the
> "canvas" as being different than the "display screen". The absolute units
> relationships should hold on the canvas and the mapping of the canvas onto
> the screen can modify ratio of absolute units to device pixels as needed
> for the device. That is, if I have a box that is 6 inches tall by 9 inches
> wide, then this box should fill a substantial part of my screen whether
> that is a monitor for a desktop computer, the Jumbotron at a sports stadium
> or a (rotated) cell phone display. The user can then position him or
> herself so that the viewing angle (which defines what size a 'px" is) is
> appropriate for reading. It is up to the User Agent to define the mapping
> of the canvas to the viewing screen (and to define "px" units). It would
> also be possible to for a UA to have a show me the canvas so that the
> absolute units are faithfully mapped to the device screen. This may require
> the canvas to be scrolled (for small devices) or make the object
> essentially invisible (for the Jumbotron).
> >
> > I will admit that I have not done the homework to work out whether the
> above proposal is effectively saying map the 'px' units to the absolute
> units, but I suspect that it is saying that, just saying it in a way that
> is one step removed from such a fixing of the 'px' size.
> >
> > Steve Z.
> >
> >
> 
> David Singer
> Multimedia and Software Standards, Apple Inc.
> 
>

Received on Thursday, 1 July 2010 21:43:11 UTC