[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