On 4/6/2011 12:32 PM, David Hyatt wrote:
He wants a way to detect Desktop zoom (which is done two different ways in
WebKit). It's difficult to figure out how to expose these, since Desktop zoom
is ultimately just the CSS zoom property, which can be applied to any element
(so folding it into a global makes little sense). The other kind of Desktop
zoom that involves a fixed scale factor applies a transform. Again, transforms
can be applied to descendant elements as well, so relying solely on what
happened to be specified at the document level makes little sense.
The descendant elements are under the control of the author.
That is, if I decide to use body.style.webkitTransform, in my scripting
environment, I'm going to know that,
because I initiated the request, and I'll add that to my calculations.
Worst case, I can always walk the DOM, grab the transform style, and use
CSSMatrix to calculate values.
With desktop zoom, the user initiates through the UA, which sends a
resize event through to window,
but the scale is not directly exposed to the scripting environment in
WebKit.
I am simply looking for the scale factor; this is an accessibility
issue, for users who are using the UA zoom.
I'm not really sure how to easily solve this problem. I suppose we could just
mix in document-level zoom and transform state into devicePixelRatio, but that
feels inelegant to me given that individual child elements can change the zoom
and transform. It wouldn't necessarily be accurate. I also don't like the
idea of having to re-resolve style just because the zoom level changed. That
would just slow things down.
Current use of window.devicePixelRatio is static, we might as well keep
it that way.
On mobile devices, authors disable UA scaling and handle the entire
process themselves.
I see adding a pixel ratio property to window.screen as the cleanest
solution.
CSS checks work, they're not slow, but they're extra work on the author,
and in-elegant,
as media matches return booleans, not float values. They're inefficient,
but not slow in any practical sense.
I'm really open to any kind of help I can give here.
I've full experience implementing the stack, from multi-level descendant
transforms starting at document.body,
to the hacks necessary to get window.screen.pixelRatio, and still
support an additional magnification AT,
such as ZoomText or the OS magnifier. I also have experience with
transform3d/webgl, but that's a different issue.
I've spoken to reps from both Google (re: TV) and Microsoft about having
distinct X and Y ratios, as MS currently does in screen.
Robert O suggested that tracking horizontal and vertical scaling
separately was unnecessary (non square pixels)
on modern displays. Both reps agreed. It doesn't harm anything, to have
both X and Y scale values, but it does not seem to be necessary.
http://msdn.microsoft.com/en-us/library/ms535868(v=vs.85).aspx
Netscape exposes the value to trusted scripts as screenPixelsPerCSSPixel
through their Utils Components interface.
https://developer.mozilla.org/en/NsIDOMWindowUtils
-Charles
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
