> On Nov 10, 2019, at 12:05 PM, Noam Rosenthal <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).

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


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

Reply via email to