Re: [webkit-dev] Content-DPR header
On Sun, May 31, 2015 at 4:54 AM, Sam Weinig wei...@apple.com wrote: Hi Yoav, Sorry, but I’m afraid I’m still not really getting it. Can you get even more concrete? Perhaps provide some a sample page that would need this kind of functionality and go through what Content-DPR values would be used? Sure. Let's take this very simple sample site http://jsbin.com/rofewawuyo/1/edit. If you wanted to optimize the image there with Client-Hints, you'd need some way to tell the browser that it has been modified, and that even though you provided it with a 400x400 pixel image, it should display it over a 200x200 CSS pixel box. A Content-DPR header value of 2 would enable the browser to know that the server has reacted to the DPR hint request header, and scale the CSS pixels it displays the image on accordingly. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Content-DPR header
On May 29, 2015, at 2:11 PM, Yoav Weiss y...@yoav.ws wrote: On Fri, May 29, 2015 at 8:34 PM, Sam Weinig wei...@apple.com mailto:wei...@apple.com wrote: Hi Yoav, Can you give a concrete example of when this will be used? I’m having trouble understanding when an author will want to change an images intrinsic size but not have control of the markup. It's not about control over markup, it's about control over style. Let's say you're now given the following task: write a script that will go over all your server's HTML files and make your images responsive by adding a `srcset` attribute to all img tags. Since some of the images may change their display dimensions at different viewport sizes (i.e the variable width use case https://dev.opera.com/articles/native-responsive-images/#variable-width-images), you want to add multiple resources with `w` descriptors to each img. Each one of these resources will be pointed towards your shiny new image server, which has access to the original high-quality image as well as the currently displayed one (the src image). But, since you don't know if all the images have their dimensions defined in CSS (and you suspect that a large chunk of them don't have CSS based dimensions), you want to make sure that the intrinsic dimensions of the displayed images remain the same even when you deliver images of varying physical dimensions. How can you achieve that? Well, the answer is, you want to modify the intrinsic size of the delivered images to be the same as the src image's intrinsic dimensions. With Content-DPR, that's easy. You simply set it to the value that is the delivered image width divided by the src image width. That way, the browser takes the Content-DPR into account, scales the delivered image and it ends up with the same intrinsic dimensions as the src image. Hi Yoav, Sorry, but I’m afraid I’m still not really getting it. Can you get even more concrete? Perhaps provide some a sample page that would need this kind of functionality and go through what Content-DPR values would be used? - Sam If you don't have markup control, the same exercise applies, but would require the full-fledged Client-Hints in order to actually deliver resized images. On May 29, 2015, at 11:23 AM, Yoav Weiss y...@yoav.ws mailto:y...@yoav.ws wrote: As a first step towards the Client-Hints implementation, I submitted a patch https://bugs.webkit.org/show_bug.cgi?id=145380 for Content-DPR support http://igrigorik.github.io/http-client-hints/#confirming-selected-dpr. A discussion followed on the thread, so I'd like to move it to the list, in order for it to get higher exposure. Content-DPR is an HTTP response header that enables style-agnostic image resizing, What exactly does style-agnostic image resizing” mean? I am not familiar with that term It's not an official term. I meant to say that it enables you to perform image resizing without taking into account the style rules that control the way in which the resized image will be displayed. by enabling the server to adapt the image's intrinsic size so that layout will not break, even if the image's dimensions are not defined in style. Opinions welcome! :) ___ 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
Re: [webkit-dev] Content-DPR header
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
Re: [webkit-dev] Content-DPR header
Hi Yoav, Can you give a concrete example of when this will be used? I’m having trouble understanding when an author will want to change an images intrinsic size but not have control of the markup. On May 29, 2015, at 11:23 AM, Yoav Weiss y...@yoav.ws wrote: As a first step towards the Client-Hints implementation, I submitted a patch https://bugs.webkit.org/show_bug.cgi?id=145380 for Content-DPR support http://igrigorik.github.io/http-client-hints/#confirming-selected-dpr. A discussion followed on the thread, so I'd like to move it to the list, in order for it to get higher exposure. Content-DPR is an HTTP response header that enables style-agnostic image resizing, What exactly does style-agnostic image resizing” mean? I am not familiar with that term by enabling the server to adapt the image's intrinsic size so that layout will not break, even if the image's dimensions are not defined in style. Opinions welcome! :) ___ webkit-dev mailing list webkit-dev@lists.webkit.org 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
Re: [webkit-dev] Content-DPR header
On May 29, 2015, at 2:11 PM, Yoav Weiss y...@yoav.ws wrote: On Fri, May 29, 2015 at 8:34 PM, Sam Weinig wei...@apple.com mailto:wei...@apple.com wrote: Hi Yoav, Can you give a concrete example of when this will be used? I’m having trouble understanding when an author will want to change an images intrinsic size but not have control of the markup. It's not about control over markup, it's about control over style. Let's say you're now given the following task: write a script that will go over all your server's HTML files and make your images responsive by adding a `srcset` attribute to all img tags. Since some of the images may change their display dimensions at different viewport sizes (i.e the variable width use case https://dev.opera.com/articles/native-responsive-images/#variable-width-images), you want to add multiple resources with `w` descriptors to each img. Each one of these resources will be pointed towards your shiny new image server, which has access to the original high-quality image as well as the currently displayed one (the src image). But, since you don't know if all the images have their dimensions defined in CSS (and you suspect that a large chunk of them don't have CSS based dimensions), you want to make sure that the intrinsic dimensions of the displayed images remain the same even when you deliver images of varying physical dimensions. How can you achieve that? Well, the answer is, you want to modify the intrinsic size of the delivered images to be the same as the src image's intrinsic dimensions. With Content-DPR, that's easy. You simply set it to the value that is the delivered image width divided by the src image width. That way, the browser takes the Content-DPR into account, scales the delivered image and it ends up with the same intrinsic dimensions as the src image. If you don't have markup control, the same exercise applies, but would require the full-fledged Client-Hints in order to actually deliver resized images. As others have said, doing this at the transport layer seems wrong. Why not just invent some new metadata that gets put into the image to describe some scaling of the intrinsic size? Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Content-DPR header
On Fri, May 29, 2015 at 8:34 PM, Sam Weinig wei...@apple.com wrote: Hi Yoav, Can you give a concrete example of when this will be used? I’m having trouble understanding when an author will want to change an images intrinsic size but not have control of the markup. It's not about control over markup, it's about control over style. Let's say you're now given the following task: write a script that will go over all your server's HTML files and make your images responsive by adding a `srcset` attribute to all img tags. Since some of the images may change their display dimensions at different viewport sizes (i.e the variable width use case https://dev.opera.com/articles/native-responsive-images/#variable-width-images), you want to add multiple resources with `w` descriptors to each img. Each one of these resources will be pointed towards your shiny new image server, which has access to the original high-quality image as well as the currently displayed one (the src image). But, since you don't know if all the images have their dimensions defined in CSS (and you suspect that a large chunk of them don't have CSS based dimensions), you want to make sure that the intrinsic dimensions of the displayed images remain the same even when you deliver images of varying physical dimensions. How can you achieve that? Well, the answer is, you want to modify the intrinsic size of the delivered images to be the same as the src image's intrinsic dimensions. With Content-DPR, that's easy. You simply set it to the value that is the delivered image width divided by the src image width. That way, the browser takes the Content-DPR into account, scales the delivered image and it ends up with the same intrinsic dimensions as the src image. If you don't have markup control, the same exercise applies, but would require the full-fledged Client-Hints in order to actually deliver resized images. On May 29, 2015, at 11:23 AM, Yoav Weiss y...@yoav.ws wrote: As a first step towards the Client-Hints implementation, I submitted a patch https://bugs.webkit.org/show_bug.cgi?id=145380 for Content-DPR support http://igrigorik.github.io/http-client-hints/#confirming-selected-dpr. A discussion followed on the thread, so I'd like to move it to the list, in order for it to get higher exposure. Content-DPR is an HTTP response header that enables style-agnostic image resizing, What exactly does style-agnostic image resizing” mean? I am not familiar with that term It's not an official term. I meant to say that it enables you to perform image resizing without taking into account the style rules that control the way in which the resized image will be displayed. by enabling the server to adapt the image's intrinsic size so that layout will not break, even if the image's dimensions are not defined in style. Opinions welcome! :) ___ webkit-dev mailing list webkit-dev@lists.webkit.org 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
