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

On Fri, 13 May 2011, Glenn Maynard wrote: > On Fri, May 13, 2011 at 12:29 AM, Ian Hickson 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

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

On Fri, May 13, 2011 at 12:29 AM, Ian Hickson 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 theoretic

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

On Fri, 13 May 2011, Glenn Maynard wrote: > On Thu, May 12, 2011 at 11:34 PM, Ian Hickson 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 Imag

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

On Thu, May 12, 2011 at 11:34 PM, Ian Hickson 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 getImageDa

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

On Fri, 11 Feb 2011, Glenn Maynard wrote: > On Fri, Feb 11, 2011 at 3:24 PM, Ian Hickson wrote: > > On Wed, 29 Dec 2010, Glenn Maynard wrote: > > > I hit this problem in a UI I worked on. It rendered into a canvas > > > the size of the window, which can be zoomed and scrolled around. > > > At

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

On Fri, Feb 11, 2011 at 3:24 PM, Ian Hickson wrote: > On Wed, 29 Dec 2010, Glenn Maynard wrote: > > I hit this problem in a UI I worked on. It rendered into a canvas the > > size of the window, which can be zoomed and scrolled around. At 100% > > full page zoom this works well. At 120% zoom, i

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

On Wed, 29 Dec 2010, Glenn Maynard wrote: > On Wed, Dec 29, 2010 at 7:38 PM, Ian Hickson wrote: > > Any UI that is based on being able to zoom content (e.g. maps is > > another one) would presumably have in-page zoom separate from UA zoom, > > but you'd still want to be able to change the UA zo

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

On Fri, Dec 31, 2010 at 8:17 PM, Charles Pritchard wrote: > Nor will it be addressed, as Mozilla has given firm notice, they've > intentionally obfuscated > the value (devicePixelRatio), in the scripting environment. I dislike seeing > that kind of behavior > in any software. It seems like the

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

Regarding: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-December/029557.html My objections have been noted throughout the threads: > It's not possible to discover the scaling of CSS pixels to actual device > pixels, with the current standard. Ian's response: "This is by design. You

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

On Wed, Dec 29, 2010 at 7:38 PM, Ian Hickson wrote: > Any UI that is based on being able to zoom content (e.g. maps is another > one) would presumably have in-page zoom separate from UA zoom, but you'd > still want to be able to change the UA zoom (changing the CSS pixel size, > essentially), sinc

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

On Fri, 19 Nov 2010, Charles Pritchard wrote: > > It's not possible to discover the scaling of CSS pixels to actual device > pixels, with the current standard. This is by design. You shouldn't need to know the actual device pixel depth, as far as I can tell. What's the use case? On Sat, 20 Nov

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

On 2010-12-18 18:58, Charles Pritchard wrote: On 11/24/2010 10:23 AM, Boris Zbarsky wrote: On 11/24/10 4:13 AM, Charles Pritchard wrote: > And, these aren't great lengths. It's about 6 lines of javascript. Uh... That depends on how your drawing path is set up. If I understand correctly what yo

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

On 11/24/2010 10:23 AM, Boris Zbarsky wrote: On 11/24/10 4:13 AM, Charles Pritchard wrote: > And, these aren't great lengths. It's about 6 lines of javascript. Uh... That depends on how your drawing path is set up. If I understand correctly what you're doing, you have to get the DPI ration (cal

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

On 12/14/2010 9:51 PM, Simon Fraser wrote: On Dec 14, 2010, at 10:22 AM, Charles Pritchard wrote: On 11/24/2010 1:12 AM, Robert O'Callahan wrote: On Wed, Nov 24, 2010 at 9:09 PM, Charles Pritchard > wrote: On 11/21/2010 4:12 PM, Robert O'Callahan wrote: On Sun

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

On 11/24/2010 1:12 AM, Robert O'Callahan wrote: On Wed, Nov 24, 2010 at 9:09 PM, Charles Pritchard > wrote: On 11/21/2010 4:12 PM, Robert O'Callahan wrote: On Sun, Nov 21, 2010 at 9:59 AM, Charles Pritchard mailto:ch...@jumis.com>> wrote: Rob: Mobile

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

On 11/24/2010 2:45 PM, Aryeh Gregor wrote: On Wed, Nov 24, 2010 at 4:38 PM, Charles Pritchard wrote: I greatly appreciate the value of standards, but I am at the same time, very sensitive to the effects that centrally planned restrictions have on groups. The aggregate effect is one where tens o

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

Kevin, I spoke with a rep on Google TV, as well as a Microsoft IE rep: neither saw an active use-case for non-square pixels. There are cases where width is stretched / squished, but they're always handled by scaling the output image. Think of fancy window manager effects, and of the ratio se

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

Am 24.11.2010 um 23:59 schrieb Charles Pritchard: > There is evidence that it will enhance usability for programmers who use it > properly. > > Focus. > > -Charles Do you mean functionality rather than usability? As I understand this, an author of a web page has neither control of nor knowle

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

On 11/24/2010 2:45 PM, Aryeh Gregor wrote: On Wed, Nov 24, 2010 at 4:38 PM, Charles Pritchard wrote: I greatly appreciate the value of standards, but I am at the same time, very sensitive to the effects that centrally planned restrictions have on groups. The aggregate effect is one where tens o

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

On Wed, Nov 24, 2010 at 4:38 PM, Charles Pritchard wrote: > I greatly appreciate the value of standards, but I am at the same time, very > sensitive to the effects that centrally planned restrictions have on groups. > The aggregate effect is one where tens of millions are harmed by the > decisions

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

On 2010/11/24 18:38 (GMT-0800) Charles Pritchard composed: I've only asked that information be made available. The response from your group seems to be "you can't handle the truth!" As a non-UA developer spectating since the beginning of this thread, my take on what you're asking for is it w

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

On 11/24/2010 10:56 AM, Boris Zbarsky wrote: On 11/24/10 1:26 PM, Charles Pritchard wrote: But the upshot is that people make mistakes. If you don't assume they will, you come to grief. Assuming they'll make mistakes is different than having zero faith in their competence. I have zero faith i

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

On 11/24/10 1:26 PM, Charles Pritchard wrote: But the upshot is that people make mistakes. If you don't assume they will, you come to grief. Assuming they'll make mistakes is different than having zero faith in their competence. I have zero faith in across-the-board competence. That is, given

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

On 11/24/2010 10:23 AM, Boris Zbarsky wrote: On 11/24/10 4:13 AM, Charles Pritchard wrote: > And, these aren't great lengths. It's about 6 lines of javascript. Uh... That depends on how your drawing path is set up. If I understand correctly what you're doing, you have to get the DPI ration (cal

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

On 11/24/10 4:13 AM, Charles Pritchard wrote: > And, these aren't great lengths. It's about 6 lines of javascript. Uh... That depends on how your drawing path is set up. If I understand correctly what you're doing, you have to get the DPI ration (call it N), change the canvas width/height by a f

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

Charles Pritchard wrote: > TV use-cases seem like they'll become more prevalent, with Apple and Google > and their devices. Apple TV doesn't have legacy connectors--only HDMI. A quick look at the specs of Google TV devices suggests that Google TV devices are also HDMI-only. The devices sold as

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

https://bugzilla.mozilla.org/show_bug.cgi?id=486200 Come on Robert: "It needs to be chrome-only because I don't want Web authors to have easy access to information about screen pixels. They'll try to defeat our zooming or size things to screen pixels, which we don't want." They defeat your z

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

Sorry about that, devicePixelRatio On 11/24/2010 1:14 AM, Robert O'Callahan wrote: On Wed, Nov 24, 2010 at 10:14 PM, Charles Pritchard > wrote: window.dpiPixelRatio does not change. Is it mozDpiPixelRatio ? There is no such property. Rob -- "Now the Bereans w

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

On 11/24/2010 1:12 AM, Robert O'Callahan wrote: On Wed, Nov 24, 2010 at 9:09 PM, Charles Pritchard > wrote: On 11/21/2010 4:12 PM, Robert O'Callahan wrote: On Sun, Nov 21, 2010 at 9:59 AM, Charles Pritchard mailto:ch...@jumis.com>> wrote: Rob: Mobile

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

On Wed, Nov 24, 2010 at 10:14 PM, Charles Pritchard wrote: > window.dpiPixelRatio does not change. > > Is it mozDpiPixelRatio ? > There is no such property. Rob -- "Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and exam

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

window.dpiPixelRatio does not change. Is it mozDpiPixelRatio ? On 11/24/2010 1:12 AM, Robert O'Callahan wrote: On Wed, Nov 24, 2010 at 9:09 PM, Charles Pritchard > wrote: On 11/21/2010 4:12 PM, Robert O'Callahan wrote: On Sun, Nov 21, 2010 at 9:59 AM, Charles

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

Message: 2 Date: Tue, 23 Nov 2010 21:53:15 -0500 From: Boris Zbarsky To: whatwg@lists.whatwg.org Subject: Re: [whatwg] Processing the zoom level - MS extensions to window.screen Message-ID: <4cec7e1b.8090...@mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 11/2

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

On Wed, Nov 24, 2010 at 9:09 PM, Charles Pritchard wrote: > On 11/21/2010 4:12 PM, Robert O'Callahan wrote: > > On Sun, Nov 21, 2010 at 9:59 AM, Charles Pritchard wrote: > >> Rob: Mobile deployments using dpiPixelRatio (as has been adopted by Moz >> and Webkit) and target-DpiDensity work well on

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

On 11/21/2010 4:12 PM, Robert O'Callahan wrote: On Sun, Nov 21, 2010 at 9:59 AM, Charles Pritchard > wrote: Rob: Mobile deployments using dpiPixelRatio (as has been adopted by Moz and Webkit) and target-DpiDensity work well on the mobile, they are not hooked t

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

On 11/23/2010 6:46 PM, Robert O'Callahan wrote: On Wed, Nov 24, 2010 at 3:30 PM, Charles Pritchard > wrote: SVG is a document format. It is not reliably implemented. It's far more expensive to implement SVG on a new environment than Canvas. So? You don't have

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

On 11/23/10 9:30 PM, Charles Pritchard wrote: Most uses of canvas involve keeping state-info around in order to redraw the screen. Quite a number do, yes. A number don't. I'll challenge you on this one: I don't think there are a number of them that don't. We may just have a different idea about

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

On Wed, Nov 24, 2010 at 3:30 PM, Charles Pritchard wrote: > SVG is a document format. It is not reliably implemented. It's far more > expensive to implement SVG on a new environment than Canvas. > So? You don't have to implement it. I can't do much for you here other than explain to you what

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

Message: 1 Date: Mon, 22 Nov 2010 15:27:40 -0500 From: Boris Zbarsky To: whatwg@lists.whatwg.org Subject: Re: [whatwg] Processing the zoom level - MS extensions to window.screen Message-ID:<4cead23c.1000...@mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On

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

On 11/23/10 5:06 PM, Robert O'Callahan wrote: On Wed, Nov 24, 2010 at 1:53 PM, Kevin Marks > wrote: Well, if we care about doing video processing with Canvas, understanding anamorphic pixels is needed. You mean the aspect ratio of the video source? Sure, bu

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

On Wed, Nov 24, 2010 at 1:53 PM, Kevin Marks wrote: > Well, if we care about doing video processing with Canvas, understanding > anamorphic pixels is needed. You mean the aspect ratio of the video source? Sure, but here we're talking about the output device. Anyway, adding APIs to help browser

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

Well, if we care about doing video processing with Canvas, understanding anamorphic pixels is needed. On Tue, Nov 23, 2010 at 4:50 PM, Robert O'Callahan wrote: > On Wed, Nov 24, 2010 at 1:24 PM, Kevin Marks wrote: > >> Most video displays have non-square pixels. Standard definition video >> proc

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

On Wed, Nov 24, 2010 at 1:24 PM, Kevin Marks wrote: > Most video displays have non-square pixels. Standard definition video > processing resolutions are 720 by 480 for NTSC and 720 by 576 for PAL though > both are 4 by 3 aspect ratio. > You can argue whether tv standards count as modern, but ther

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

Most video displays have non-square pixels. Standard definition video processing resolutions are 720 by 480 for NTSC and 720 by 576 for PAL though both are 4 by 3 aspect ratio. You can argue whether tv standards count as modern, but there are a lot out there. On 21 Nov 2010 16:56, "Robert O'Callah

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

On 11/22/10 12:22 AM, Charles Pritchard wrote: OpenGL has an immediate-mode which does not require a bitmap backend. Sure. But if it's going to be resolution independent, then there needs to be a retained mode somewhere in the stack, even if it's not exposed to the original caller (e.g. you

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

On 11/22/10 12:30 AM, Robert O'Callahan wrote: On Mon, Nov 22, 2010 at 8:49 PM, Charles Pritchard > wrote: On 11/21/10 10:51 PM, Robert O'Callahan wrote: On Mon, Nov 22, 2010 at 6:22 PM, Charles Pritchard mailto:ch...@jumis.com>> wrote: I've a deep a

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

On Mon, Nov 22, 2010 at 8:49 PM, Charles Pritchard wrote: > On 11/21/10 10:51 PM, Robert O'Callahan wrote: > > On Mon, Nov 22, 2010 at 6:22 PM, Charles Pritchard wrote: > >> I've a deep and detailed understanding of the SVG, HTML, DOM and CSS >> specs. >> > > Just out of interest, why aren't you

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

On 11/21/10 10:51 PM, Robert O'Callahan wrote: On Mon, Nov 22, 2010 at 6:22 PM, Charles Pritchard > wrote: I've a deep and detailed understanding of the SVG, HTML, DOM and CSS specs. Just out of interest, why aren't you using SVG? Many thanks for the SVG Filter

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

On Mon, Nov 22, 2010 at 6:22 PM, Charles Pritchard wrote: > I've a deep and detailed understanding of the SVG, HTML, DOM and CSS specs. > Just out of interest, why aren't you using SVG? I understand the need to make canvas backing store pixels map to device pixels when possible. Suppose that, o

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

On 11/21/10 6:30 PM, Boris Zbarsky wrote: On 11/21/10 8:31 PM, Charles Pritchard wrote: Canvas is an immediate mode rendering framework. I realize that it uses a bitmap backend, Isn't that more or less a requirement for "immediate mode"? After all, the whole issue is that when resolution cha

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

On 11/21/10 4:56 PM, Robert O'Callahan wrote: On Mon, Nov 22, 2010 at 1:40 PM, Charles Pritchard > wrote: I would point out that the MS proposal has an independent X and Y scaling mechanism. Does anyone know of any modern displays which have different X and Y r

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

On Mon, Nov 22, 2010 at 1:40 PM, Charles Pritchard wrote: > I would point out that the MS proposal has an independent X and Y scaling > mechanism. > Does anyone know of any modern displays which have different X and Y resolution? > I believe that dpi ratio is simply set to "2" (or .5... sorry

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

On 11/21/10 4:12 PM, Robert O'Callahan wrote: On Sun, Nov 21, 2010 at 9:59 AM, Charles Pritchard > wrote: Rob: Mobile deployments using dpiPixelRatio (as has been adopted by Moz and Webkit) and target-DpiDensity work well on the mobile, they are not hooked to

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

On Sun, Nov 21, 2010 at 9:59 AM, Charles Pritchard wrote: > Rob: Mobile deployments using dpiPixelRatio (as has been adopted by Moz and > Webkit) and target-DpiDensity work well on the mobile, they are not hooked > to zoom on the desktop, > It is in Firefox. > and they were not designed for de

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

On Mon, Nov 22, 2010 at 10:07 AM, Aryeh Gregor > wrote: > On Sat, Nov 20, 2010 at 12:21 AM, Robert O'Callahan > wrote: > > Most of the use cases for script access to the exact device pixel ratio > that > > I've heard boil down to "interfere with the user's ability to zoom", > which > > is why I

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

On Sat, Nov 20, 2010 at 12:21 AM, Robert O'Callahan wrote: > Most of the use cases for script access to the exact device pixel ratio that > I've heard boil down to "interfere with the user's ability to zoom", which > is why I haven't been eager to make it easier. Might there be some web pages tha

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

On 11/20/10 3:59 PM, Charles Pritchard wrote: This response is from the digest: I'm glad to see activity here. Canvas is supposed to be resolution independent, No, it's not. Vector images are supposed to be resolution independent. Canvas is very explicitly a _bitmap_. It's not a vector imag

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

This response is from the digest: I'm glad to see activity here. As I can't figure out how to hit reply in thread, I'll take some editorial discretion here and just summarize it, so we can make a decision on the use case. Ojan calls for: "good use-cases for the general web", Boris implies that

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

On Sat, Nov 20, 2010 at 9:49 AM, Simon Fraser wrote: > On Nov 20, 2010, at 7:46 AM, Ojan Vafai wrote: > To be clear, chrome.tabs.getZoomPercentage is a Chrome extension API. Having > extensions that can mess with zoom seems like a legit use-case. But I agree, > I can't think of good use-cases for

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

On Nov 20, 2010, at 7:46 AM, Ojan Vafai wrote: > On Fri, Nov 19, 2010 at 9:21 PM, Robert O'Callahan > wrote: > Most of the use cases for script access to the exact device pixel ratio that > I've heard boil down to "interfere with the user's ability to zoom", which is > why I haven't been eager

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

On Fri, Nov 19, 2010 at 9:21 PM, Robert O'Callahan wrote: > Most of the use cases for script access to the exact device pixel ratio > that I've heard boil down to "interfere with the user's ability to zoom", > which is why I haven't been eager to make it easier. > To be clear, chrome.tabs.getZoom

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

On Sat, Nov 20, 2010 at 10:42 AM, Boris Zbarsky wrote: > We (Mozilla) have no plans to expose screen pixels to untrusted content at > the moment, more or less as a policy decision. > We actually do support the -moz-device-pixel-ratio CSS media query. There are legitimate use cases for that. Mos

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

On 11/19/10 3:04 PM, Charles Pritchard wrote: Mozilla: window.QueryInterface(Components.interfaces.nsIInterfaceRequestor).getInterface(Components.interfaces.nsIDOMWindowUtils).screenPixelsPerCSSPixel Note that if you try to do this in a web page, it will throw. That entire interface is mostly

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

It's not possible to discover the scaling of CSS pixels to actual device pixels, with the current standard. There are three non-standard ways to access them, from what I can see. Mozilla: window.QueryInterface(Components.interfaces.nsIInterfaceRequestor).getInterface(Components.interfaces.nsIDO