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, [email protected] wrote:
Date: Fri, 19 Nov 2010 12:04:53 -0800
From: Charles Pritchard<[email protected]>
.....
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<[email protected]>
.....
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"<[email protected]>
.....
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<[email protected]>
.....
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<[email protected]>
...
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."<[email protected]>
...
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
