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 19:26:55 UTC