RE: [css3-mediaqueries] DPI in resolution media queries

Warning: simplifications ahead.

> 
> All I know is that when I specify an inch, I expect it to mean an inch.
> 
> Authors are not interested in the technical mumbo-jumbo that means their
> request for one inch turns out to be up to 1/3 different. They want an
> inch, because they've requested an inch. Not a CSS inch, not roughly an
> inch. An actual inch.

First, browsers depend on the OS to know what an inch is on the screen.
They have no way of knowing whether it actually amounts to an inch on
the display. You can call it mumbo-jumbo all you want. They ask the
platform for what an inch is and can only assume it's the right size.

Second, there is no "CSS inch". There is a CSS pixel that is different
from a device pixel because it's defined as 1/96 of an inch. So on a
a 96dpi screen, 96 CSS pixels == 96 device pixels == 1 inch. Voila.
As you adjust your DPI up or down, the number of device pixels per
CSS pixels changes but if your new DPI is not a multiple of 96 then
representing a CSS pixel and keeping the 96px==1 inch equivalency is
no longer possible. Again, call it mumbo-jumbo all you want. These are 
the tools you have to work with and they come with hard physical
constraints.

> 
> Therefor, there is a problem. There's a problem with CSS's language as it
> doesn't produce the expected result. "ahhh, but when you *say* inch you
> are being understood to mean *a CSS inch*" is no use. Common sense should
> trump implementation quirks. 

Physics trumps common sense. See above. Sorry.

> The argument for keeping an incorrect result
> incorrect because it always used to be incorrect isn't one that makes
> sense to me when it's something as fundamental as a unit of measure that
> is currently wrong more often than right.

I think we're drifting away from Lea's concern. I'm still not sure I 
understand what she thinks is broken but I can try to clarify what
the resolution means in simple - I hope - terms.

When you zoom a page, the browser increases the number of device pixels 
per CSS pixel. So a width:96px box will still be as wide as the width:1in 
box on the same page. But they'll both look 2 inches wide on the screen 
because you zoomed the page. So now the question is: when you use dpi/dpcm, 
do the inch/centimeter in the ratio reflect the zoomi factor i.e. does
the dpi go up as you zoom because the number of physical dots for each
page inch is in fact increasing? Or should the value stay fixed?

I honestly have no opinion. It ought to depend on what you use the
feature for. 

> 
> Right now it's like some weird legalese where everyone's talking about
> winning a cash prize of £1000 but the money in the bank ends up as
> £831 and the rationale is because in tiny text somewhere the £ symbol was
> defined to mean something other than the commonly understood value. "Oh no,
> when we say a £ we mean a 2001 £, not the current £".

That's not weird at all. It's called taxes, exchange rates and many other
names :)

> 
> 
> On 16 February 2012 20:11, Lea Verou <leaverou@gmail.com> wrote:
> > Opened netmagazine.com today, found yet another article documenting
> > the
> > problem:
> > http://www.netmagazine.com/features/where-are-our-absolute-css-units

> > The writer seems to be under the impression that this is a browser bug
> > that goes against the spec.
> >
> > I wonder what exactly is needed to convince you guys that this is a
> > real problem that needs a solution (any solution!).
> >
> >
> > On 15/2/12 18:34, Sylvain Galineau wrote:
> >>
> >> [Lea Verou:]
> >>>
> >>> Subject: [css3-mediaqueries] DPI in resolution media queries (was: Re:
> >>> [CSSWG] Minutes and Resolutions Paris F2F 2012-02-08 Wed AM I:)
> >>>
> >>> 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.
> >>
> >> Possible being the key word here. If and when the OS can give the UA
> >> accurate info, then it is possible for every driver/peripheral that
> >> tells the OS the truth.
> >>
> >>> 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?!
> >>
> >> It'd be easier to understand the mistake(s) given use-cases. Or
> >> better, links to sites that depend on Gecko's behavior as you
> >> understand it?
> >>
> >>
> >>
> >>
> >> --
> >> Lea Verou (http://lea.verou.me | @LeaVerou)
> >
> >

Received on Friday, 17 February 2012 02:53:48 UTC