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

Thanks Rick. It seems strange to me to lump together user zoom and  
device pixel ratio. While they might share a code path in many (or  
even most) instances, they're conceptually quite different. One is  
manually configurable on the fly by the user, and one is a fixed  
hardware characteristic. I see no reason why this should introduce  
bugs. Zoom is a multiplier just like dpr, just a different multiplier.

There's a demonstrated desire of authors to be able to detect zoom  
independently of dPR, for all sorts of reasons. One use case is  
accessibility: a css layout for low-sighted users who have their  
browser  zoom set to a massive multiplier. This currently breaks  
layout on most sites, even responsive ones. (Setting media breakpoints  
in ems fixes some, but not all of the problems.) Another use case  
would be the artistic one, in which content or layout changes  
creatively on zoom, allowing user to create exploratory  
layouts-within-layouts that users can pinch-zoom their way into and  
around.

To put it baldly: Browser zoom is already (by definition) exposed to  
the user. Why isn't it exposed to the author?

Alex

Quoting Rick Byers <rbyers@chromium.org>:

> 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.
>
> Rick
>

Received on Friday, 6 December 2013 12:33:59 UTC