There's a thread about this here:
http://lists.w3.org/Archives/Public/www-style/2012Nov/0282.html
http://lists.w3.org/Archives/Public/www-style/2012Nov/0179.html

I'm not sure a consensus was reached. John, do you think we should do this?

Google Maps would like this feature. As they draw the new maps they'd like to draw at high-resolution (1x1 device pixels) and apply the zoom in their code rather than have the browser auto-scale a low-res canvas.

> John, do you think we should do this?

Yes, I still think we should do this.

I don't know of any formal definition for window.devicePixelRatio, but the most useful and consistent way I can see to define it is: << the ratio between DIPs and physical device pixels, where a DIP is the size that a CSS pixel would be if the page were to have a "width=device-width, maximum-scale=1" viewport >>.

Under this definition, desktop full page zoom changes the viewport width, and hence the size of DIPs. So we should adjust devicePixelRatio accordingly (both the JS property and the -webkit-device-pixel-ratio and resolution media queries).

I'd also argue that we should go all in and scale the values of screen.availWidth et al to match. It should be impossible for the website to detect that full page zoom is being applied: instead when zoomed in it should just appear that the page is being displayed in a slightly smaller window on a slightly smaller screen with higher pixel density.

See also the recent changes we've made so media queries respond correctly to full page zoom, in issue 245449 and http://wkbug.com/53186.

I think we need to discuss this on the blink mailing list and maybe cross post to webkit-dev

Here's the discussion thread on the blink mailing list that spurred the recent activity on this bug: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/fRWlQ3GvlVA ("Intent to Implement: window.screen.canvasResolution")

Note that it's currently by-design that devicePixelRatio doesn't include browser zoom (I think that's what the 'device' really means in the name), but I agree browser zoom should be exposed somewhere.  We need to be careful that, for example, pinch-zoom doesn't ever cause relayout (which can result in jank).  See http://trac.webkit.org/wiki/ScalesAndZooms for a description of the different types of scales/zooms.

Related - webkit-image-set should take browser zoom into account (I believe that was always the intention, but was never implemented).

I support #6. People from several vendors (IE/FF/Chrome/Opera) agreed in the thread mentioned in #2 that devicePixelRatio/resolution should change on "desktop full page zoom", but not on pinch-zoom. 

Cool - if the major browsers are on board, and we can do this without causing any major breakage on the web, then I'd love to see this changed too (despite the confusion over the name).  Perhaps the next step is to do this behind a flag and see what (if anything) breaks?

Doing it without breaking existing use cases and web apps is the tricky part. Assuming this is the path we decide to go down.

What about exposing a new property like window.screen.resolution instead of devicePixelRatio. The latter is not specified in any spec anyway and it seems that canvas is going for window.screen.canvasResolution

Or maybe window.screen.pageResolution or documentResolution ?

> Doing it without breaking existing use cases and web apps is the tricky part.

Why? It should be indistinguishable to websites whether they are running on a small high dpi screen or a large low dpi screen with full page zoom (desktop Ctrl-+) applied. Since websites all work today when running on small high density screens, they should all work in the latter case too.

The only part I worry about is that devicePixelRatio could now change while a website is open (which was already theoretically possible when a window is moved between monitors). If this turns out to be a big problem we can always fix devicePixelRatio based on the zoom level when the page first loaded (so in practice we'd only modify devicePixelRatio when persisting a full page zoom that was previously set on a page from the same domain) - this wouldn't be ideal, but would still be an improvement.

> What about exposing a new property like window.screen.resolution instead of devicePixelRatio.

devicePixelRatio is a de facto standard, supported by Chrome, Safari, Opera, Firefox[1] and possibly soon IE[2].

I doubt we'll be able to remove it. So it doesn't seem worth adding a duplicate with a different name (especially since resolution is ambiguous[3], and is often used to mean pixel dimensions). And adding a near-duplicate which behaves differently in an obscure edge-case which most web devs don't consider sounds even worse :)

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=564815
[2]: http://msdn.microsoft.com/en-us/library/ie/dn255104
[3]: http://en.wikipedia.org/wiki/Display_resolution

OK, I didn't know that MS also added support for it. Then it seems even more confusing with the canvasResolution name.

You would also need to update the value whenever the viewport changes due to new meta viewport or @viewport rule.

Why not bring this up on webapps so that we can get it in HTML5 like the canvasResolution?

Agreed that devicePixelRatio should not include browser zoom. IMHO, devicePixelRatio should reflect only a property of the physical device (screen), not any browser or content settings.

AFAICT, combining page zoom into devicePixelRatio means the web app cannot make decisions about assets: it cannot distinguish between a hiDPI device at 1X page zoom and a loDPI device at 2X zoom.

I would find that loading a page on a loDPI device and zooming in 2X causing network re-fetches to get hiDPI assets to be quite surprising, especially if the content cannot opt out of that behaviour.

If the browser does not reload assets automatically on page zoom, then a reload after zoom of the page would presumably cause the new assets to be loaded, and a different visual result. I would also find that surprising.

I would much prefer a separate ratio. This leaves it up to the content to examine the two ratios and decide what to do.

I also don't think consensus was reached on the quoted thread. From smfr:

"We (Apple) feel quite strongly that device-pixel-ratio, like window.devicePixelRatio,
should not change under zoom. It's answering a question about the device hardware,
not the current zoom state of the page."

http://lists.w3.org/Archives/Public/www-style/2012Nov/0164.html

Web pages can already opt-in to this behavior. They can keep using the value of devicePixelRatio when the page loaded, or they can monitor it for updates.

Example 1: Open google.com/maps/preview on a loDPI display and drag it to a hiDPI display. The map image is fuzzy and doubled in size.

Example 2: Open apple.com on a loDPI display and drag it to a hiDPI display. A script then downloads several dozen images.

> I also don't think consensus was reached on the quoted thread. From smfr:
>
> "We (Apple) feel quite strongly that device-pixel-ratio, like
> window.devicePixelRatio,
> should not change under zoom. It's answering a question about the device hardware,
> not the current zoom state of the page."

I can't be 100% sure, would need to ask Simon, but I think that statement is about pinch-zoom, not about the CSS pixel "zoom" that this issue is about.

kenneth.christiansen wrote:
> You would also need to update the value whenever the viewport changes due to new meta viewport or @viewport rule.

No, devicePixelRatio should not be affected by the viewport tag/rule. That doesn't happen today, and it would be confusing and break compatibility to do so.

That's why my definition in #6 defined DIPs in terms of a "width=device-width, maximum-scale=1" viewport, so they would be independent of the actual viewport.


senorblanco wrote:
> combining page zoom into devicePixelRatio means the web app (...) cannot distinguish between a [small] hiDPI device at 1X page zoom and a [large] loDPI device at 2X zoom

Yes, that's by design. Because in both cases each DIP represents a 2x2 square of physical device pixels, and so in both cases you need to load double resolution assets. The two cases truly are identical.

> I would find that loading a page on a loDPI device and zooming in 2X causing network re-fetches to get hiDPI assets to be quite surprising

As I said in #17, we can debate whether devicePixelRatio should change while a webpage is open (though there has already been discussion of refetching image-set/srcset assets when browser windows are moved between high and low dpi screens). But let's at least fix this for the persistent full page zoom case.

> If the browser does not reload assets automatically on page zoom, then a reload after zoom of the page would presumably cause the new assets to be loaded, and a different visual result.

If assets get sharper after reloading the page, users either won't notice, or will be happy.

> I would much prefer a separate ratio. This leaves it up to the content to examine the two ratios and decide what to do.

Like I said in #17, having two near-duplicate ratios that only differ in an obscure edge-case (desktop full page zoom), guarantees that many web developers will use the wrong one and select the wrong assets etc in the presence of full page zoom.


rune wrote:
> I can't be 100% sure, would need to ask Simon, but I think that statement is about pinch-zoom, not about the CSS pixel "zoom" that this issue is about.

That's my understanding as well. Unfortunately Simon/Apple didn't reply to clarify this, but the consensus from all other vendors on the thread (Opera, IE, Chrome, Firefox) was that devicePixelRatio should change in response to full page zoom (Ctrl-+ on desktop).

Could we change the bug title to say that this is related to content upscaling (Desktop browser zoom), and thus not the initial-zoom which can be modified with viewport meta etc.

I like us to use the terminology that Rune used in the CSS Device Adaptation spec, thus referring to the "initial viewport".

I'd like to point out that currently, the resolution media query does not
take the zoom factor into account.
If window.devicePixelRatio would change according to zoom (which would be a
good thing IMO), the resolution/devicePixelRatio media queries should
follow the same logic.

Assinging to Emil.  You're actively working on this, right?

Yeah, I'll send out the intent to implement notice later this week.

https://codereview.chromium.org/23000005/

The following revision refers to this bug:
    http://src.chromium.org/viewvc/blink?view=rev&rev=156040

------------------------------------------------------------------------
r156040 | eae@chromium.org | 2013-08-13T19:31:45.748177Z

Changed paths:
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/dom/Window/device-pixel-ratio-on-zoom-expected.txt?r1=156040&r2=156039&pathrev=156040
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/page/RuntimeEnabledFeatures.in?r1=156040&r2=156039&pathrev=156040
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/dom/Window/device-pixel-ratio-on-zoom.html?r1=156040&r2=156039&pathrev=156040
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/page/DOMWindow.cpp?r1=156040&r2=156039&pathrev=156040

Update window.devicePixelRatio on browser zoom

Update window.devicePixelRatio on full page zoom so that it
accurately portraitists the ratio between css and device pixels.

This matches the behavior of Firefox and the IE 11 preview.

BUG= 177836 
R=eseidel@chromium.org, dglazkov@chromium.org
TEST=fast/dom/Window/device-pixel-ratio-on-zoom.html

Review URL: https://chromiumcodereview.appspot.com/23000005
------------------------------------------------------------------------

Added as an experimental feature, once verified the plan is to turn it on for M31.

https://code.google.com/p/chromium/issues/detail?id=177836#c25

^ if that does indeed happen, this will start triggering new image downloads when you zoom? =\ .. If so, that's probably not the behavior we want?

> If so, that's probably not the behavior we want?

Why do you say that?  Why would that be different from dragging the screen to a monitor with a different device scale?

>> If so, that's probably not the behavior we want?
>Why do you say that?  Why would that be different from dragging the screen to a monitor with a different device scale?

Unless I'm missing something.. a) zoom triggers new download (which is weird on its own, how will the UA replace the image? blank out the previous, and wait for new one? This may take *a while*.. if you hold and show the old picture, then once again, download will take a while (on mobile), by which point the user zooms back out - wasted download). And perhaps even more importantly: you're likely on a high-DPI device, you have a high DPI image loaded, and zoom will trigger a lower DPI download -- this makes no sense. We already have the higher resolution image in place, which will generate better visual quality, and no unnecessary downloads. 

Why would images re-download unless you manually are polling devicePixelWidth (or checking it onresize) and then replacing them yourself?

I don't think there is an event being introduced here

This event will not trigger for page scale on mobile.  Pinch zooming on mobile != page zoom.

I'm responding to: https://code.google.com/p/chromium/issues/detail?id=177836#c25

If media queries inherit this same logic on zoom, than background image downloads will get triggered automatically... Worse, if someone is actually using DPR as a design breakpoint, it may force a full reflow / layout?

Maybe we should take this conversation off-bug - you seem a bit confused.  Changing page zoom always forces a full layout - that's how it works.

> Pinch zooming on mobile != page zoom.

"Unless I'm missing something..." - indeed, looks like I was. Thanks for the clarification -- all good then. :)

The following revision refers to this bug:
    http://src.chromium.org/viewvc/blink?view=rev&rev=156113

------------------------------------------------------------------------
r156113 | rune@opera.com | 2013-08-14T20:41:15.661116Z

Changed paths:
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/css/MediaQueryEvaluator.cpp?r1=156113&r2=156112&pathrev=156113
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/page/DOMWindow.cpp?r1=156113&r2=156112&pathrev=156113
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/css/zoom-media-queries-resolution-expected.txt?r1=156113&r2=156112&pathrev=156113
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/page/Frame.cpp?r1=156113&r2=156112&pathrev=156113
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/page/Frame.h?r1=156113&r2=156112&pathrev=156113
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/css/zoom-media-queries-resolution.html?r1=156113&r2=156112&pathrev=156113

Let page zoom affect resolution and -webkit-device-pixel-ratio MQs.

In order to make them consistent with the recent change for
window.devicePixelRatio (r156040).

BUG= 177836 

Review URL: https://chromiumcodereview.appspot.com/23192002
------------------------------------------------------------------------