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

Comments

Projects
None yet
4 participants
@igrigorik

igrigorik commented Nov 11, 2014

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

This comment has been minimized.

Show comment
Hide comment
@tabatkins

tabatkins Nov 15, 2014

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?

tabatkins commented Nov 15, 2014

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

This comment has been minimized.

Show comment
Hide comment
@igrigorik

igrigorik Nov 15, 2014

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.

igrigorik commented Nov 15, 2014

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

This comment has been minimized.

Show comment
Hide comment
@vigneshshanmugam

vigneshshanmugam Nov 15, 2014

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

vigneshshanmugam commented Nov 15, 2014

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

This comment has been minimized.

Show comment
Hide comment
@tabatkins

tabatkins Nov 17, 2014

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

tabatkins commented Nov 17, 2014

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

@igrigorik

This comment has been minimized.

Show comment
Hide comment
@igrigorik

igrigorik Nov 17, 2014

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 commented Nov 17, 2014

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.

@eeeps eeeps referenced this issue Mar 6, 2015

Closed

Meeting! #164

@igrigorik

This comment has been minimized.

Show comment
Hide comment
@igrigorik

igrigorik Dec 27, 2015

bump ... any blockers for making this happen?

igrigorik commented Dec 27, 2015

bump ... any blockers for making this happen?

@zcorpan

This comment has been minimized.

Show comment
Hide comment
@zcorpan

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

This comment has been minimized.

Show comment
Hide comment
@igrigorik

igrigorik Jan 8, 2016

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

igrigorik commented Jan 8, 2016

@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