W3C home > Mailing lists > Public > www-style@w3.org > February 2012

[css3-mediaqueries] DPI in resolution media queries (was: Re: [CSSWG] Minutes and Resolutions Paris F2F 2012-02-08 Wed AM I:)

From: Lea Verou <leaverou@gmail.com>
Date: Wed, 15 Feb 2012 18:20:34 +0200
Message-ID: <4F3BDB52.4050207@gmail.com>
To: www-style list <www-style@w3.org>
This basically renders resolution media queries *completely useless*, at 
least in screen media types, just like inches and cm lengths currently are.
With the increasing diversity of devices and their resolutions, this 
would've been tremendously useful to help maintain a readable, 
comfortable experience no matter the screen DPI. There is currently *no 
way* to do that.
UAs have shown that it *is* possible to implement this as physical DPI, 
for example that's what Gecko does.
I understand the legacy reasons behind defining the in and cm units with 
a fixed dpi, but there are no legacy reasons to screw this one up. Yes, 
it might be more consistent, but what's really the value of being 
consistent with mistakes?!

Cheers,
Lea (lea.verou.me | @leaverou on Twitter, Github, Dribbble)


On 12/2/12 03:17, fantasai wrote:
>
>
> Media Queries
> -------------
>
>   - RESOLVED: dpi/dpcm in 'resolution' media query uses CSS units.
>   - RESOLVED: In section 4.11 ('resolution'), append after the first
> paragraph
>               "For printers, this corresponds to the screening
> resolution (the
>                resolution for printing dots of arbitrary color)."
> [...]
>
> Media Queries
> -------------
>
>   Florian: When defining <resolution> in MQ, we didn't specify whether
>            they are CSS in and cm, or whether they follow the usual
>            definition
> <dbaron> http://dev.w3.org/csswg/css3-mediaqueries/#units
>   dbaron: So the first sentence of section 6
>   dbaron: "The units used in Media Queries are the same as in other parts
>            of CSS. For example, 'px' represents CSS px, not device
> pixels."
>   Florian: Definition of dpi doesn't say though
>   Florian: Also other spec that redefines <resolution> makes it explicit
>            that these are CSS inches etc.
>   Florian: But this spec is not explicit.
>   ...
>   fantasai: dots are device pixels
>   Question is what is the inch.
>   dbaron: I think in our case it's a physical inch, not a CSS inch.
>   sylvaing: Do you want number of device pixels per CSS inch or per
> physical
>             inch?
> <dbaron> http://dev.w3.org/csswg/css3-images/#resolution-units
>   * Bert thinks we can go ask what an inch is: We're in Paris, not far
>     from
> http://en.wikipedia.org/wiki/InternationalBureauofWeightsandMeasures :-)
>   Steve: I think dp physical inch makes most sense
>   fantasai: Problem is that if you try to use resolution and width to
>             calculate the dots across the width, you can't if the inches
>             don't match up
>   dbaron: What are people using resolution for?
>   Florian: They aren't, they're using device-pixel-ratio
>   smfr: Webkit doesn't support 'resolution'
>   sylvaing: What do you do with that?
>   smfr: You decide whether you load high-res implementations or not.
>   dbaron: I would like to know what other implementations do, since this
>           has been in CR a long time
>   Florian: We did CSS inches for a long time, but recently started, on
>            mobile-only, doing physical inches, but only on mobile.
>   plinss: Being inconsistent makes no sense
>   dbaron: Doing CSS sizes is much harder because you have to proxy all
>           your device pixel ratio computations into resolution
>   dbaron: I guess we just compute it entirely ...
>   dbaron: But that would mean you can't get the physical size of the
> device.
>   Florian: This doesn't give you physical size of a display
>   dbaron: I wrote a script that did multi-step computation to find the
>           physical size of a device
>   Florian: [...]
>   Steve, summarizing Florian: The CSS pixel is intended to encapsulate
>     viewing distance and size together because that's what actually
>     matters to the viewer.
>   plinss: I think if we interpret inches differently in different places
>           we're asking for trouble.
>   ChrisL: Does that mean you can get the number of physical dots per
> CSS px.
>
> <dbaron>
> http://lists.w3.org/Archives/Public/www-style/2008Apr/thread.html#msg126
> <dbaron> oh, wait, that was about the dot part rather than the inch part
>   dbaron: I don't see this thread having a clear conclusion
>   Tab: Answer to original question of whether dots are CSS px or
> device px
>
>   ChrisL: If so, what do you get from a printer?
>   Tab: What's the problem here?
>   Tab: Are printers lower-res than dots?
>   ChrisL: The screen resolution is a lot smaller than the device
> resolution
>   ChrisL: for a printer
>   ChrisL: they combine ink colors to make a color
>   ChrisL: So should we clarify printer situation?
>   Tab: Yes, let's clarify that the device pixel in this case is the dot
>        of arbitrary color.
>   ChrisL: So the screening resolution
>   Florian: The whole point of this is to supply high-res images
>   ChrisL: but if they're choosing high-res vs low-res images, and they
>           get back 200dpi from the printer as the screen res?
>   ChrisL: The author who wants to figure out whether they have a high-res
>           printer will expect 1200dpi
>   Tab: Difference between high-res screen (~200dpi) and printer should
>        be easy to distinguish
>   ChrisL: A typical screening resolution is 175dpi
>   fantasai: Question is, if the screening resolution is 200dpi and the
>             other resolution is 1000dpi, do I send the printer a 200dpi
>             image or a 1000dpi image?
>   Koji: To answer fantasai's question, if it's a monochrome image you
>         should use 1000dpi, and if it's color or grayscale you should
>         send 200dpi
>   fantasai: We can't make that distinction in Media Queries
>   fantasai: To make that distinction you need both resolutions, and we're
>             only providing one.
>   ChrisL: The author can assume that 1000dpi gets you 200dpi screening
>   fantasai: What if someone creates a device that has screening 600dpi
>   Steve: Why not add a media query on screening?
>   ChrisL: You need the physical dots per inch as well.
>   Steve: No, instead of reporting actual results, ... it has to be
> reported
>          with the same assumptions as the other resolutions.
>   Steve: If you add a media query for screening, it's going to report
>          information back. All I'm saying is that as long as the
>          information is reported using the same assumptions as the other
>          media query things, that will tell you whether the dpi is
>          different from screening resolution and by how much.
>   ChrisL: Given what you've just said, if I have high-res printer, what
>           number do I send back?
>   fantasai: Most people send images that are more than one color. So we
>             should return the resolution that is applicable to that.
>   fantasai: and add a media query that gives the other number, if needed
>   ChrisL: Add "Therefore for printers this is the screening resolution."
>   tab: Need explanation for non-printer-geeks
>   fantasai: I like Tab's suggestion of "dot of arbitrary color".
>   ChrisL: Should have both.
>
>   sylvaing: Since when we zoom, we change the number of physical pixel
>             to CSS px
>   sylvaing: As soon as you zoom, you change whether the media query
> matches
>   fantasai: you have the same problem with device-width, which is already
>             known to be in CSS inches.
>   fantasai: you need to exclude zoom from this.
>   dbaron: I think FF has a bug with zooming
>   dbaron: But I don't think what happens with zooming correlates with
>           whether we're also including snapping to CSS px/in definition
>   Florian: So based on that you're comfortable defining in terms of
> CSS px
>   sylvaing: seems like it
>   Rossen: Looking through the code it looks like we are doing CSS px/in
>   plinss: Proposed to resolve as dpi/dpcm in CSS inches/cm
>   dbaron: I'm not particularly happy with it, but okay.
>   Florian: Unhappy that we're changing now, or unhappy about what we're
>            changing to.
>   dbaron: both
>   Florian: We have to change too. Allowing use of 'resolution' in place
>            of 'device-pixel-ratio' also makes more sense this way
>   sylvaing: This is the author-facing behavior.
>   sylvaing: it's got to be CSS px/in
>   dbaron: Can I tentatively accept and double-check with roc?
>
>   Bert: Question about what this means. It's confusing.
>   Bert: So I'm looking at iphone display, sold as 326dpi
>   Bert: What would be the CSS resolution in that case?
>   Florian: It depends
>   plinss: You're in the mobile pinch-zoom world,
>   Florian: Fairly likely that resolution in dppx would be 2
>   dbaron: It would be 192dpi
>   sylvaing: When you do zoom in FF, what do you do?
>   dbaron: I don't actually know
>   sylvaing: talks about a testcase that changes bg color
>
>   Florian: Is anyone aware of common use of 'resolution' in the wild
>   dbaron: Probably not because webkit doesn't implement it
> <dbaron> For the record, roc is ok with the proposed change to the
>            resolution media query.
>   RESOLVED: dpi/dpcm in 'resolution' media query uses CSS units.
>
>   plinss: To close loop on Chris's tangent on screening.
>   fantasai: The proposal is to define resolution as screening resolution,
>             and explain what that means.
>   Section 4.11
>   Append after the first paragraph in the 'resolution' section
>   "For printers, this corresponds to the screening resolution (the
>    resolution for printing dots of arbitrary color)."
>   RESOLVED: Accept proposal for clarifying 'resolution' MQ for printers.
>   ACTION Florian: File an issue on MQ4 about adding the other resolution
>                   (for monochrome printing)
> <trackbot> Created ACTION-439
>
Received on Wednesday, 15 February 2012 16:21:10 GMT

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