Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

API for getting/setting image pixel density #252

Open
igrigorik opened this issue Nov 11, 2014 · 8 comments
Open

API for getting/setting image pixel density #252

igrigorik opened this issue Nov 11, 2014 · 8 comments

Comments

@igrigorik
Copy link

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:

@tabatkins
Copy link

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?

@igrigorik
Copy link
Author

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.

@vigneshshanmugam
Copy link

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

@tabatkins
Copy link

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

@igrigorik
Copy link
Author

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.

@igrigorik
Copy link
Author

bump ... any blockers for making this happen?

@zcorpan
Copy link

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?

@igrigorik
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants