W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2010

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

From: Glenn Maynard <glenn@zewt.org>
Date: Wed, 29 Dec 2010 20:16:43 -0500
Message-ID: <AANLkTi=OiYU=-3KLHcTVOB_w_N536=QrGoSkJOkCsuHj@mail.gmail.com>
On Wed, Dec 29, 2010 at 7:38 PM, Ian Hickson <ian at hixie.ch> wrote:
> Any UI that is based on being able to zoom content (e.g. maps is another
> one) would presumably have in-page zoom separate from UA zoom, but you'd
> still want to be able to change the UA zoom (changing the CSS pixel size,
> essentially), since you would want to be able to zoom the page UI itself.

I hit this problem in a UI I worked on.  It rendered into a canvas the
size of the window, which can be zoomed and scrolled around.  At 100%
full page zoom this works well.  At 120% zoom, it creates a canvas
smaller than the window, which is then scaled back up by the browser,
resulting in a blurry image.  Full page zoom should work on the UI
around it--I didn't want to disable it entirely--but the canvas itself
should be created in display pixels, rather than CSS pixels.

I didn't find any reasonable workaround.  All I can do is tell people
not to use full-page zoom.  Many users probably see a blurry image and
don't know why, since there's no way to detect full-page zoom in most
browsers to even hint the user about the problem.

Glenn Maynard
Received on Wednesday, 29 December 2010 17:16:43 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:02 UTC