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

On Sat, Nov 20, 2010 at 12:21 AM, Robert O'Callahan
<robert at ocallahan.org> wrote:
> 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.

Might there be some web pages that have good reason to interfere with
the user's ability to zoom?  For instance, Google's "Quick View" for
PDFs:

http://docs.google.com/viewer?a=v&q=cache:D8hHb4MTkS4J:www.irs.gov/pub/irs-pdf/fw4.pdf

(Apparently the W-4 form is the first PDF hit when you Google for
"PDF", who knew.)  Over at the side there are zoom buttons, but they
do something quite different from using the browser's built-in zoom
function.  However the in-page zoom buttons work is a lot more legible
and smooth than using browser zoom.  So allowing the page to hijack
browser zoom requests in this specific case would actually be a
usability improvement, as far as I can tell.

But I haven't looked at how the page works.  Maybe there'd be some
superior way to do it so that browser zoom worked as well as the
provided zoom buttons.  But users might still expect zoom buttons, so
perhaps zoomIn()/zoomOut() methods would be useful, in the same vein
as print().  (Such methods don't exist yet, do they?  I don't see much
abuse potential if they did -- if you can only say "zoom in" or "zoom
out", they're not good for much except in-page zoom buttons, and you
could emulate the effect through sufficiently tortuous JavaScript.)

Received on Sunday, 21 November 2010 13:07:35 UTC