[webkit-dev] Content-DPR: Image resolution optimization at CDN/transport layer

Noam Rosenthal noam at webkit.org
Tue Nov 12 00:46:59 PST 2019


On Tue, Nov 12, 2019 at 3:28 AM Alexey Proskuryakov <ap at webkit.org> wrote:

>
>
> 10 нояб. 2019 г., в 1:16 AM, Noam Rosenthal <noam at webkit.org> написал(а):
>
> Also, as a response to the view that this should be part of markup, I
> would argue that those transparent decisions by the servers should not
> concern web authors at all. It’s an optimization decision to be handled by
> the servers, with the user agent doing nothing about it but allow that
> decision to be transparent in terms of layout (the same way gzip and
> cache-control are transparent).
>
>
> I don't see this as a precedent, because cache control and compression are
> invisible to users.
>
Agreed, I was showing it as an example that HTTP headers are a valid place
to add instructions to/from transient layers of the internet (CDN/proxy).
Though, for example, the good old "Accept" header may result in receiving a
different image encoding for the same URL, resulting in different qualities
for the same URL.


> Whereas image quality most certainly is. Changing it behind both web
> developer and user back would cause lots of undesirable behaviors - say, I
> e-mail an image from a webpage to someone else, who doesn't have a small
> display, or just zoom in to see the details.
>
This basically results in the website being untestable by the author (or by
> UA implementers who will be getting bug reports about site behavior
> differences).
>

This can already happen, a URL for an image doesn't guarantee always
receiving the same resource. Content-DPR doesn't change that. On the
contrary, by providing Content-DPR we allow such optimizations (which
already take place) to avoid breaking layouts that are based on intrinsic
image sizes, which is the main way websites can break due to serving
different images to the same image request URL. The web today is based on
this premise - the same URL may lead to different resources in different
situations.

Also, we don't change it behind the web developer's back - who maybe does
that is the developer's chosen CDN, and it's a legitimate
experience/performance tradeoff that can be negotiated between them. What
we can do as a browser engine, is do the minimum to prevent that behavior
from breaking layouts.

>

> Also, maybe I'm just pessimistic here, but it seems almost inevitable that
> disagreements between markup, Content-DPR and dpi information embedded in
> images will be handled by UAs differently, even if the spec ends up being
> very detailed on this point.
>
I'm less pessimistic about that. Content-DPR is quite clear - it's a
description of the content, like an encoding

~Noam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20191112/2c41602c/attachment.htm>


More information about the webkit-dev mailing list