[whatwg] Processing the zoom level - MS extensions to window.screen
robert at ocallahan.org
Sun Nov 21 16:10:24 PST 2010
On Mon, Nov 22, 2010 at 10:07 AM, Aryeh Gregor
<Simetrical+w3c at gmail.com<Simetrical%2Bw3c at gmail.com>
> 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
> > I've heard boil down to "interfere with the user's ability to zoom",
> > 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
> (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.
I don't mind a browser allowing a page to override the default behavior of a
browser's zoom keybindings or possibly even menu items. But ultimate control
still has to reside with the user and user-agent. Web designers are
notorious for declaring that their content should be viewed at a certain
size; if an obnoxious designer tries to disable browser zooming, I insist
that the browser be able to override that.
"Now the Bereans were of more noble character than the Thessalonians, for
they received the message with great eagerness and examined the Scriptures
every day to see if what Paul said was true." [Acts 17:11]
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the whatwg