W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2011

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

From: Ian Hickson <ian@hixie.ch>
Date: Fri, 13 May 2011 04:29:05 +0000 (UTC)
Message-ID: <Pine.LNX.4.64.1105130427550.16840@ps20323.dreamhostps.com>
On Fri, 13 May 2011, Glenn Maynard wrote:
> On Thu, May 12, 2011 at 11:34 PM, Ian Hickson <ian at hixie.ch> wrote:
> >
> > No, ImageData exposes the underlying data, not the data in CSS pixels.
> 
> I know.  That's what I was responding to: having different backing store 
> dimensions and dimensions exposed by ImageData doesn't make sense.
> 
> If you mean that getImageData might return data of different dimensions 
> than the canvas coordinate space (which I see the spec allows), that 
> sounds like it would cause major interop problems if anyone actually did 
> that.  It's very unobvious and I'd expect most people to miss it.

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).


> 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.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 12 May 2011 21:29:05 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:06 UTC