Re: [webkit-dev] Content-DPR header

[Sam Weinig]

> On May 29, 2015, at 2:11 PM, Yoav Weiss  wrote:
> 
> On Fri, May 29, 2015 at 8:34 PM, Sam Weinig  > 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  tags. Since some of the images may change 
> their display dimensions at different viewport sizes (i.e the "variable 
> width" use case 
> ),
>  you want to add multiple resources with `w` descriptors to each . 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 > > wrote:
>> 
>> As a first step towards the Client-Hints implementation, I submitted a patch 
>>  for Content-DPR support 
>> .
>> 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

Re: [webkit-dev] Content-DPR header

[Yoav Weiss]

On Sat, May 30, 2015 at 12:32 AM, Simon Fraser 
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