On Sat, May 30, 2015 at 12:32 AM, Simon Fraser <simon.fra...@apple.com> wrote:
> > As others have said, doing this at the transport layer seems wrong. > 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. Content-DPR can be thought of as part as the regular content-negotiation flow, where the browsers may indicate "this is what I need" (e.g. via Client-Hints request headers) and the server can indicates "this is what I gave you". > > Why not just invent some new metadata that gets put into the image to > describe some scaling of the intrinsic size? > Well, several reasons: * 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. * Introducing meta data to do that would require a significant effort on multiple fronts: - 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). - We would need to add support for that to the decoding code of all these formats. - 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.
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
