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

On Fri, 19 Nov 2010, Charles Pritchard wrote:
>
> It's not possible to discover the scaling of CSS pixels to actual device 
> pixels, with the current standard.

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?


On Sat, 20 Nov 2010, Simon Fraser wrote:
> On Nov 20, 2010, at 7:46 AM, Ojan Vafai wrote:
> >
> > I can't think of good use-cases for the general web being able to [get 
> > this information].
> 
> The only one I can think of is sizing the canvas backing store to get a 
> sharp image on high-resolution displays

You get this automatically, if you specify the size of the canvas in CSS 
pixels.


> and possibly swapping in different image assets from JS.

That's an interesting use case.


On Sun, 21 Nov 2010, Aryeh Gregor wrote:
> 
> 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.)

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.


On Sat, 20 Nov 2010, Charles Pritchard wrote:
> 
> Sizing the backing store and swapping image assets is exactly the use 
> case I'm working with.

I could see a need to swap image assets so that the UA gets the assets 
that are the highest resolution assest appropriate for the device at the 
current zoom.

It seems that the best way to do that is to use a technique similar to 
what operating systems use for icons and cursors: have image files that 
expose all the various sizes of data, and then have the UA pick the right 
size when painting the image. That seems out of scope for HTML, though.


> Canvas is supposed to be resolution independent, not resolution 
> agnostic. When a user zooms in, I need to be able to reprint my fillText 
> to match their resolution.

When the zoom changes, you should get a resize event, so in theory you 
can already do that. (Or use SVG.)

The 'resize' event is an issue for one of Anne's specs, though.

[snip many e-mails that didn't really cover use cases]


On Mon, 22 Nov 2010, Robert O'Callahan wrote:
> 
> I understand the need to make canvas backing store pixels map to device 
> pixels when possible. Suppose that, on clearing the canvas (e.g. by 
> setting the width or height attribute), the browser automatically set 
> the canvas backing store density so that canvas backing store pixels map 
> to device pixels (taking into account the current zoom settings). 
> Suppose further that browsers fired the 'resize' event when they zoom in 
> a way that changes the window size (as they should, even if they 
> currently don't). Then on 'resize' you could clear your canvas and 
> redraw it, and automatically get a canvas backing store with the right 
> resolution with no further code changes.

What you describe here is essentially what I would expect of all 
implementations. It is certainly within the realm of what is allowed by 
the specs.


On Mon, 22 Nov 2010, Charles Pritchard wrote:
>
> My attention is still on exposing metrics so I can repaint to the device 
> resolution, fully within the existing standard. I don't want to change a 
> thing about CSS/Canvas; just looking for some data to be available in 
> the DOM.
> 
> It's a DOM deficiency in relation to the canvas tag.
>
> Google Books demonstrates a use case apart from Canvas. They don't need 
> to override the browser's zoom. They do provide their own icon. If the 
> browser did provide information, about zoom, they could send a higher 
> resolution image to the browser for that portion.

That's not really about zoom, it's about native resolution -- e.g. if the 
user printed the page, you'd want to provide data in the printer's native 
resolution rather than the screen's. That's something that you'd want to 
do regardless of JS being enabled or not, so it can't be a scripting API 
-- it has to be an underlying feature of the graphics rendering. The 
aforementioned model whereby graphics come in multiple resolutions seems 
like the best way to solve this problem for bitmap data; for vector data, 
you'd just want to use something like SVG.

Either way, this seems like a graphics layer issue, not an HTML issue. 
It could be solved using media queries at the image level, for instance.

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

Received on Wednesday, 29 December 2010 16:38:28 UTC