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

David,
  Thank you for clarifying the role of resolution in this discussion. I was hoping that it could be avoided, but,  as you correctly point out, it has an important role.

What I believe you are pointing out is that there are good reasons for the device to "lie" for both kinds of use cases provided that the MQs only ask about physical size. (A better intentioned author should be having both physical size and resolution in his MQs. Then, the author gets to choose what he thinks is the best way to present his content for the device responding to the MQs.)

What concerns me about this state of affairs is it tends to create a war between the browsers and the authors that want to do the right thing. The browser "lie" so that content without suitable MQs gets a "reasonable" presentation, but such "lies" make it difficult for the author to adapt his content to do an even better job for a class of devices. (Yes, I am aware that new classes of devices will continue to be added the mix.)

Given that "resolution" can be queried, is adding a physical size query, for which lying would be non-conforming, sufficient to solve the problem. That is, as is already done, lies would be permitted for the existing size queries, but resolution and "true" size must be reported correctly or be non-conforming. This gives the UA maker a way to get reasonable results with unprepared pages and the author a way to prepare better pages for classes of devices.

Steve Zilles


> -----Original Message-----
> From: David Singer [mailto:singer@apple.com]
> Sent: Thursday, July 01, 2010 2:53 PM
> To: Stephen Zilles
> Cc: Sylvain Galineau; tantek@cs.stanford.edu; www-style@w3.org list
> Subject: Re: [CSS21] Issue 149 - px vs. pt
>
>
> 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 22:51:58 UTC