> On Nov 10, 2019, at 2:13 PM, Maciej Stachowiak <m...@apple.com> wrote:
>> On Nov 10, 2019, at 12:05 PM, Noam Rosenthal <n...@webkit.org 
>> <mailto:n...@webkit.org>> wrote:
>> On Sun, Nov 10, 2019 at 9:41 PM Maciej Stachowiak <m...@apple.com 
>> <mailto:m...@apple.com>> wrote:
>> Is this header useful without the DPR client-hint?
>> Absolutely. 
>> A server/CDN can decide to serve an image with a particular content-dpr 
>> without knowing the client's actual DPR.
> A few more questions (apologies if there are basic things that would be 
> explained by a spec somewhere).

Following up on one of these questions...

> - Is there a specification for Content-DPR? All I could find in bugzila and 
> elsewhere is links to <https://httpwg.org/http-extensions/client-hints.html 
> <https://httpwg.org/http-extensions/client-hints.html>>, which does not 
> mention Content-DPR at all).

Looks like the ChangeLog links here: 
which is an expired Internet-Draft for Client Hints. The latest Internet-Draft 
(-07, as well was the in-progress -08) no longer mentions Content-DPR. Is there 
a new place where this is specified?

> - Can you give us some examples of how the CDN would make the decision of 
> what density of image to serve without knowing the client’s DPR via  
> client-hints? 
> - Is this presuming situations where the CDN serves the images but not the 
> markup or CSS (which presumably could be rewritten to account for DPR)?
> - What happens if Content-DPR is provided, but the markup or CSS has 
> conflicting explicit info? For example, <img srcset=“image-2x.jpg 2x, 
> image.jpg 1x”>, and image-2x.jpg is served with a Content-DPR header of 3x. 
> Or the analogous thing with CSS.
> - Does Content-DPR have any effect on images where an explicit size is 
> provided, either in markup or in CSS? (I’m assuming no.)
> Cheers,
> Maciej
>>> On Nov 10, 2019, at 1:16 AM, Noam Rosenthal <n...@webkit.org 
>>> <mailto:n...@webkit.org>> wrote:
>>> Hola
>>> I would like to open a discussion that has started a few years back and has 
>>> never reached a consensus: https://bugs.webkit.org/show_bug.cgi?id=145380 
>>> <https://bugs.webkit.org/show_bug.cgi?id=145380>
>>> In a nutshell: content-dpr is a response-only header for images, that 
>>> allows servers at transient layers (CDNs/proxies) to optimize images by 
>>> changing their resolution, allowing the user agents to compensate for the 
>>> change in intrinsic size caused by the resolution change - thus making the 
>>> resolution change transparent to users. It's the header that makes the 
>>> resolution-encoding transparent.
>>> The feature is already up and running in chrome since version 67, and is 
>>> used by some CDNs.
>>> Since there was lack of consensus in the bug discussion, I wanted to make 
>>> the case for it here, and see if opinions about the subject can be voiced 
>>> before we reach a decision/consensus. I tried to find a good balance 
>>> between being detailed and being concise. 
>>> —
>>> Players in CDN, proxy and other transient parts of the internet world have 
>>> innovated a lot in the past few years. There are lots of interesting 
>>> companies and competition there. One of the areas of this innovation is in 
>>> optimizing images in a transparent way at transient layers (proxy/CDN). 
>>> This makes a lot of sense considering how much of internet traffic is taken 
>>> by image download.
>>> What the research at the CDN companies found, was that modifying resolution 
>>> at the transient layer can have a tremendous effect on 
>>> performance/user-experience balance, for example by serving 
>>> lower-resolution versions of the images when network traffic is costly/slow 
>>> (the exact formula for that is part of where the CDN can innovate). More 
>>> details on that innovation in the links below.
>>> The thing is, that modifying image resolution at the CDN/proxy is not 
>>> inherently transparent, due to one reason - layout is affected by the 
>>> image’s intrinsic size, and changing the image’s resolution inadvertently 
>>> changes the image’s intrinsic size. To make this transparent, the user 
>>> agent has to be involved, to compensate for this optimization when reading 
>>> the image’s intrinsic size.
>>> The main case against this feature was that image resolution is a feature 
>>> that should be handled at the markup layer and not at the transport layer 
>>> (https://bugs.webkit.org/show_bug.cgi?id=145380#c7 
>>> <https://bugs.webkit.org/show_bug.cgi?id=145380#c7>).
>>> I would argue that http-headers are not a transport layer (TCP/UDP etc.), 
>>> but rather part of an application-layer protocol that is designed, in part, 
>>> to pass information to the transient layers such as CDNs, and that 
>>> resolution compression is a (new, image-specific) equivalent of 
>>> transfer-encoding. 
>>> 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).
>>> What is offered here is a win-win in terms of delivering images, and would 
>>> allow webkit-browser users to enjoy some of the innovations in the image 
>>> delivery world without modifying their HTML content and without concern of 
>>> breaking their layouts. Less battery and data used for downloading big 
>>> images at certain situations, for example.
>>> I hope this provides enough background without being too tedious. I would 
>>> be happy to shed more light on whatever is missing in this longish essay :)
>>> Additional info:
>>> https://github.com/eeeps/content-dpr-explainer 
>>> <https://github.com/eeeps/content-dpr-explainer>
>>> https://cloudinary.com/blog/client_hints_and_responsive_images_what_changed_in_chrome_67
>>> <https://cloudinary.com/blog/client_hints_and_responsive_images_what_changed_in_chrome_67>
>>> https://www.chromestatus.com/metrics/feature/timeline/popularity/906 
>>> <https://www.chromestatus.com/metrics/feature/timeline/popularity/906>_______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>>> <https://lists.webkit.org/mailman/listinfo/webkit-dev>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> <https://lists.webkit.org/mailman/listinfo/webkit-dev>
webkit-dev mailing list

Reply via email to