W3C home > Mailing lists > Public > www-style@w3.org > December 2013

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

From: Alex Bell <alex@bellandwhistle.net>
Date: Wed, 09 Oct 2013 19:45:49 +0000
Message-ID: <20131009124513.20092n9mnjtz9geh@webmail.bellandwhistle.net>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Rick Byers <rbyers@chromium.org>, Simon Sapin <simon.sapin@exyr.org>, "www-style@w3.org" <www-style@w3.org>, "eae@chromium.org" <eae@chromium.org>
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. 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.

Lumping together zoom and DPR is a "better path" in the sense that  
it's easier for implementors, 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.

So, partly for historical reasons, in this case I just don't buy the  
"it's hard, there might be bugs" argument. dPR didn't even really  
meaningfully exist just a few years ago.  Also, massive changes are  
coming. @viewport is initially going to create huge swarms of bugs.  
Any @viewport compliant browser will have to internally calculate zoom  
very differently anyway, starting in the very near future. Given that  
Device Adaptation is (hopefully) coming, and it's probably "hard" to  
implement, why not expose zoom? All of this is still very much in  
formation. The status quo is not a long-term option. I think now is  
the time to address zoom with standards, before the @viewport  
codebases are baked-in, and even more onerous to revisit later on.

Thanks again,

Quoting "Tab Atkins Jr." <jackalmage@gmail.com>:

> On Wed, Oct 9, 2013 at 8:08 AM, Rick Byers <rbyers@chromium.org> wrote:
>> Note that there's been several recent discussions on blink-dev about this,
>> eg:
>> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/RyUSi3zdumQ.
>> https://code.google.com/p/chromium/issues/detail?id=177836
>> The consensus was to match FF behavior and update devicePixelRatio and
>> associated media queries to reflect browser zoom - that this was both
>> consistent with the standard for the 'resolution' media query, and
>> sufficient for application needs (with Google Docs as an example of a very
>> demanding applications here).  There was even rough agreement that this was
>> better than exposing two separate concepts (pixel ratio and browser zoom
>> level) to the application - that doing so would just lead to bugs and
>> applications should be treating both in the same way.
>> I don't personally have more detailed context than that, but this sounds
>> like a much better path than introducing another new API.
> Yeah, this is much better.  Obviously, the existing 'resolution' media
> query would reflect that as well.  (Well, it would reflect its
> inverse.)
> ~TJ
Received on Friday, 6 December 2013 12:33:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:37 UTC