API for getting/setting image pixel density #252

igrigorik opened this Issue Nov 11, 2014 · 8 comments


None yet

4 participants


Currently the UA "remembers" which DPR variant it picks when making a request and then uses said value to scale the received asset before it's displayed - e.g. if a 2x selector is used, then the image is automatically scaled down by same factor before its displayed.

However, there are cases where what the client chooses, and what comes back (from server, cache, service worker, etc), are not the same:

  • Client requests a 2x asset, but server/cache does not have it available and wants to return a 1x asset. Today, this would result in an incorrectly scaled asset once displayed.
  • ServiceWorker intercepts requests and goes on to automate/rewrite fetches to account for device DPR - there is no way for SW to communicate to UA the DPR value of the fetched asset. This is also an issue if SW synthesizes a response - e.g. user is offline, and only a lower resolution asset is available.
  • If the developer fetches an arbitrary Blob/ArrayBuffer (via XHR or other means), it would be nice to provide a JS API where the pixel density can be set/updated + queried on the element.

To address above use cases, we need two things:


Yeah, I don't see anything wrong with the idea, and being able to set the default densities of things seems useful.

Are you just asking for the sizing algo to check this header on the response and respond accordingly?


Yes, I guess there are two different things here, although they are related in terms of API surface...

  1. Check for the Content-DPR header and use it for calculating the intrinsic size. Note that this value should override the client's default - e.g. client requests a 2x, but server responds with 1.5x.
  2. Provide a JS API to do the same.. for cases where I'm fetching a blob and want to feed it to img, etc.

Just Curious to know. In the case of offline, Will it returns the image from cache and scales it automatically or wont render the image from cache?.


Presumably we'd have to cache its server-specified resolution along with it. Then it'd scale automatically.


HTTP response headers are cached (we need them for Accept+Vary processing, ETags, etc), so that's not an issue, the value will be available when coming from cache.


bump ... any blockers for making this happen?

zcorpan commented Jan 4, 2016

It's not clear to me that Client-Hints will be adopted by all browsers. I would recommend monkey-patching HTML in the CH spec for the header part for now.

The JS API can be added, but I don't know what behavior you would like it to have. Should the default be a special "auto" value that has today's behavior, and if you set it to a number, that number gets used even if a new resource is selected? Or something else?


@zcorpan monkey patch HTML spec from an IETF doc? Yikes.. If anything, I think it would make sense to do the reverse: move Content-DPR from CH into HTML spec. It came about because we first stumbled into the need for this when working on CH, but it's useful (and needed) outside of CH - e.g. you're serving assets from a ServiceWorker and need to communicate the DPR of the asset, such that it's displayed correctly.

JS API: I'd expect the query to return the DPR of the current resource; if the resource changes it should return the new value.

@JosefJezek JosefJezek referenced this issue in GoogleChrome/sw-helpers Jul 10, 2016

Helper for responsive images #24

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment