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

Ian Hickson ian at hixie.ch
Thu May 12 22:56:41 PDT 2011


On Fri, 13 May 2011, Glenn Maynard wrote:
> On Fri, May 13, 2011 at 12:29 AM, Ian Hickson <ian at hixie.ch> wrote:
> > 
> > It's pretty much the entire point of that API. That's why it has 
> > separate height/width information than the canvas. It has to be that 
> > way because there's no guarantee that CSS pixels will map to device 
> > pixels -- and that's not theoretical, there are shipping devices with 
> > high-density screens already (e.g. the iPhone).
> 
> It's still unobvious and doesn't happen on desktop browsers, so I can't 
> see it not causing broken pages.  To people developing on desktops, it 
> just looks like a 1:! 2d slice API that stashes the size in the 
> ImageData for convenience, which is all I've ever seen it as, having 
> never seen it behave otherwise.

Yes, it's possible the getImageData() API is doomed to only exposing CSS 
pixels, in which case we'll likely add an argument so people can opt-in to 
the high-res version once technology has advanced such that doing so would 
likely not give a 1:1 mapping in most cases. (There's no point doing that 
today, since we'd just end up in the same problem again currently.)

This has been discussed a _lot_ on this list over the past few years. I 
recommend searching for "putImageData" and "getImageData" in the archives.

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



More information about the whatwg mailing list