W3C home > Mailing lists > Public > www-style@w3.org > July 2010

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

From: David Singer <singer@apple.com>
Date: Thu, 1 Jul 2010 14:52:43 -0700
Cc: Sylvain Galineau <sylvaing@microsoft.com>, "tantek@cs.stanford.edu" <tantek@cs.stanford.edu>, "www-style@w3.org list" <www-style@w3.org>
Message-Id: <5F26EF84-2B67-407F-AEE1-195DBFE04FE6@apple.com>
To: Stephen Zilles <szilles@adobe.com>

On Jul 1, 2010, at 14:42 , Stephen Zilles wrote:

> 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! 

Indeed, I don't think so.  

I am concerned I think this is not recognizing the devices which are intended to be viewed at 'unusual' distances:
* hi-res handhelds, which want to tell the page that they are (for example) 8x6 in when in fact they are 4x3, because the users view them close and they have a high dpi
* lo-res projection screens etc., which want to tell the page that they are (for example) 9x16 in, when, in fact, they are 90x160in, because they are lo-res and the users look at them from miles away.

In both these cases, I think some are arguing that the devices should 'tell the truth' about their true physical dimensions, and true dpi.  Maybe we didn't do a good job of managing this before, because we ended up having to pretend everything was 96dpi.

I guess one way forward would be to have CSS units (Elika's message, as edited, that had the two 'anchor' systems) and also true units (truepx, truedpi, truein, truecm, truemm, truepc) where we say that the dpi *does* vary, but that, to the extent possible, these match physical reality on the device, and if there is no physical surface on which to measure them, match the CSS units (which are backward-compatible).  It's not pretty, but it is clean and consistent.

I am not sure if this actually solves the use cases, though.  I'm serious, I think we need real examples of "I want to do MQs and CSS for this page that will lay out in correct physical units on any device, but especially these, so that it looks like this and this and this" and see exactly what we're trying to solve.

> 
> 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.

I share your unease...

> 
> 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.
>> 
>> 
> 

David Singer
Multimedia and Software Standards, Apple Inc.
Received on Thursday, 1 July 2010 21:53:20 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:29 GMT