> 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: https://tools.ietf.org/html/draft-ietf-httpbis-client-hints-06#section-3.1.1 <https://tools.ietf.org/html/draft-ietf-httpbis-client-hints-06#section-3.1.1> 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 webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
