<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, May 30, 2015 at 12:32 AM, Simon Fraser <span dir="ltr">&lt;<a href="mailto:simon.fraser@apple.com" target="_blank">simon.fraser@apple.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><span class=""><div><br></div></span><div>As others have said, doing this at the transport layer seems wrong.</div></div></blockquote><div><br></div><div>HTTP is an application layer protocol, and is already used to convey all kinds of data about the payload that it delivers, such as content-type, charset and language. Content-DPR is not very different. </div><div>Content-DPR can be thought of as part as the regular content-negotiation flow, where the browsers may indicate &quot;this is what I need&quot; (e.g. via Client-Hints request headers) and the server can indicates &quot;this is what I gave you&quot;. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>Why not just invent some new metadata that gets put into the image to describe some scaling of the intrinsic size?</div><span class=""><font color="#888888"><div></div></font></span></div></blockquote></div><br></div><div class="gmail_extra">Well, several reasons:</div><div class="gmail_extra">* The same image resource can be used over multiple scenarios (e.g. a 600px wide image can be used as a 300px image on a retina screen, as well as a 600px image on a 1x screen). In each scenario, the image would need to have a different intrinsic size.</div><div class="gmail_extra">* Introducing meta data to do that would require a significant effort on multiple fronts:</div><div class="gmail_extra"> - We would need that meta data to work the same way across all currently used Web image formats (GIF, PNG, JPEG, SVG, JPEG-2000, WebP and JPEG-XR). </div><div class="gmail_extra"> - We would need to add support for that to the decoding code of all these formats. </div><div class="gmail_extra"> - We would need the various utilities that create these images to add support for editing this meta data. This would require a huge eco-system wide effort.</div></div>