[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