> 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.) 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 https://lists.webkit.org/mailman/listinfo/webkit-dev
