[whatwg] Processing the zoom level - MS extensions to window.screen

[Charles Pritchard]

This response is from the digest: I'm glad to see activity here.
As I can't figure out how to hit reply in thread, I'll take some editorial
discretion here and just summarize it, so we can make a decision on the 
use case.

Ojan calls for: "good use-cases for the general web",

Boris implies that discussion hasn't been open on the topic.

Rob reminds us of that a poor use case will "interfere with the user's 
ability to zoom".

Simon puts forward two use cases:
"sizing the canvas backing store to get a sharp image on high-resolution 
displays, and possibly swapping in different image assets from JS."

TJ promptly minimizes the use cases:
"sure, that's a somewhat valid reason, but still very minor."

And now I have the floor:

Sizing the backing store and swapping image assets is exactly the use 
case I'm working with. This is a serious issue for accessibility.

Canvas is supposed to be resolution independent, not resolution 
agnostic. When a user zooms in, I need to be able to reprint my fillText 
to match their resolution.

This data is critical for accessibility, to make text legible.

Boris, Rob: As an accessibility use case, this is quite important. 
Please let me know if there are objections.

Ojan: setZoomLevel is already available through document.body.zoom. As a 
browser extension, those items are fine. But they don't address the use 
cases I've outlined.
I feel the same about the moz extension.

Rob: Mobile deployments using dpiPixelRatio (as has been adopted by Moz 
and Webkit) and target-DpiDensity work well on the mobile, they are not 
hooked to zoom on the desktop,
and they were not designed for desktop-style zoom. Trying to overload 
these variables leads to difficulties between the various mobile style 
zooms and desktop zoom.

To all of you: I understand that these proposals hinge on reasonable use 
cases. This is a simple extension to implement and relates to an 
existing deficiency, not a new feature.
It relates to the correct operation of "zoom": fixing this is an 
accessibility requirement.



On 11/20/2010 12:08 PM, whatwg-request at lists.whatwg.org wrote:
> Date: Fri, 19 Nov 2010 12:04:53 -0800
> From: Charles Pritchard<chuck at jumis.com>
.....
> I'm pushing Microsoft's solution, of exposing the data through
> window.screen.
> Can we all get on board with that one? Are there other proposals?
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 19 Nov 2010 16:42:47 -0500
> From: Boris Zbarsky<bzbarsky at MIT.EDU>
.....
> We (Mozilla) have no plans to expose screen pixels to untrusted content
> at the moment, more or less as a policy decision.
>
> Why do you need this information, exactly?
>
> ------------------------------
>
>
> Message: 3
> Date: Sat, 20 Nov 2010 18:21:25 +1300
> From: "Robert O'Callahan"<robert at ocallahan.org>
.....
> We actually do support the -moz-device-pixel-ratio CSS media query. There
> are legitimate use cases for that.
>
> Most of the use cases for script access to the exact device pixel ratio that
> I've heard boil down to "interfere with the user's ability to zoom", which
> is why I haven't been eager to make it easier.
>
> Rob
>
>
>
> Message: 4
> Date: Sat, 20 Nov 2010 07:46:12 -0800
> From: Ojan Vafai<ojan at chromium.org>
>
.....
> To be clear, chrome.tabs.getZoomPercentage is a Chrome extension API. Having
> extensions that can mess with zoom seems like a legit use-case. But I agree,
> I can't think of good use-cases for the general web being able to.
>
> Ojan
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Sat, 20 Nov 2010 09:49:55 -0800
> From: Simon Fraser<smfr at me.com>
>
...
> The only one I can think of is sizing the canvas backing store to get a sharp image on high-resolution displays, and possibly swapping in different image assets from JS.
>
> Simon
>
> ------------------------------
>
> Message: 6
> Date: Sat, 20 Nov 2010 10:12:21 -0800
> From: "Tab Atkins Jr."<jackalmage at gmail.com>
...
> The author can't control the size of the backing store, though (unless
> you mean, for example, keeping a 1-to-1 canvas, instead of making the
> canvas half-size and then upscaling it with CSS).
>
> The latter sure, that's a somewhat valid reason, but still very minor.
>   (And using vector images gets around the issue entirely.)
>
> ~TJ