- From: Alex Bell <alex@bellandwhistle.net>
- Date: Wed, 09 Oct 2013 19:45:49 +0000
- 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, Alex 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