Re: [mediaqueries4] zoom-ratio as a media feature

On Wed, Oct 9, 2013 at 12:45 PM, Alex Bell <alex@bellandwhistle.net> wrote:
> Well, the 'resolution' feature in MQ4 describes:
>
> "The ‘resolution’ media feature describes the resolution of the output
> device, i.e. the density of the pixels."
>
> Obviously, browser zoom doesn't change a device's hardware pixel density.

Yes, it does, at least as far as you can tell.  Zooming means less CSS
pixels fit into a given number of hardware pixels, which means the
resolution is lower.

Note that I'm referring to layout-affecting zoom, like what you get
from Ctrl-+ or the like.  Viewport zooming, like what you get on
mobile devices when looking at large sites, doesn't change the size of
the viewport, and isn't relevant to this.

> On
> the face of it, this is just glaringly semantically wrong. I'm hope you
> understand the burning frustration of authors on this point. Folks at CSS
> conferences are right to publicly shame implementations that change
> resolution based on zoom.

If you can come up with a use-case that actually needs the literal
pixel density of the device, please do so.  Every use-case I've ever
seen that cares about density wants the ratio of CSS px to device
pixels, which includes browser zoom.

> Lumping together zoom and DPR is a "better path" in the sense that it's
> easier for implementors,

It's not any easier.  They're two separate numbers internally;
exposing them as two attributes vs exposing their product as one
attribute is basically the same.

> and because it's the status quo of two
> implementations. But both FF and Chrome were different just last year, and
> they broke a lot of code on the recent change without any positive benefit
> that I can see. There are bugs now. Maybe Google Docs just isn't running
> into them.

Actually, Google Docs *did*, because they were (and still are) doing
some silly things with zoom that make the damned thing *not* zoom.
Use the density for what it's intended for (drawing in <canvas>,
basically), and you'll be fine.

~TJ

Received on Wednesday, 9 October 2013 20:20:55 UTC