[whatwg] Processing the zoom level - MS extensions to window.screen
Glenn Maynard
glenn at zewt.org
Thu May 12 21:55:35 PDT 2011
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.
> Anyway, this doesn't help this case in general anyway because the
> > full-screen zoom level can change at any time.
>
> Sure, but there's not much that can be done for that case.
>
If so, only due to vendors digging in their heels insisting "we don't
*really* want to do that"...
--
Glenn Maynard
More information about the whatwg
mailing list