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

On Wed, 29 Dec 2010, Glenn Maynard wrote:
> 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.

That's a bug in the browser. If it knows it's going to be zooming up the 
canvas when it creates the backing store, it should be using a bigger 
backing store.


On Fri, 31 Dec 2010, Charles Pritchard wrote:
> 
> My objections have been noted throughout the threads:
> 
> > It's not possible to discover the scaling of CSS pixels to actual 
> > device pixels, with the current standard.
> 
> Ian's response:
> 
> "This is by design. You shouldn't need to know the actual device pixel 
> depth, as far as I can tell. What's the use case?"
> 
> It's necessary to know CSS pixel scaling to match the backend bitmap 
> with the device.
> This is common, active practice on mobile devices:
>  <canvas width="200" style="width: 100px;">

It may be necessary to know the CSS pixel scaling to match the backend 
bitmap with the device today, but this is only because of bugs in the 
browsers. The solution isn't to add a feature to the spec, and then wait 
for the browsers to implement it, that lets you work around the bug in 
browsers. The solution is for the browsers to fix the bug instead.


> I see Canvas and the scripting environment as a part of the graphics 
> layer, whereas it seems many on the list feel that the graphics layer 
> should not be handled by authors.

By "graphics layer" I meant CSS, media queries, and image decoders.

<canvas> is intended to be device-agnostic.


> My use case, regarding Google Books, is not about printing. It was 
> simply about using a computer screen, with the zoom level turned up. 
> That's it. If you go to Google books, and your zoom level is turned up, 
> the image displayed will be upscaled, with some possible blurriness. 
> This could be avoided, by simply exposing the CSS pixel ratios, so that 
> the image would match the correct scaling.

I went to books.google.com, opened up the first book in my library, and 
zoomed in, and it reflowed and rerendered the text to be quite crisp. I 
don't see any problem here. Images were similiarly handled beautifully.

Could you elaborate on the steps to reproduce this problem?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 11 February 2011 12:24:14 UTC