W3C home > Mailing lists > Public > public-respimg@w3.org > November 2013

Re: [client-hints] new v1 spec draft and src-N interop

From: Ilya Grigorik <igrigorik@google.com>
Date: Thu, 31 Oct 2013 20:21:04 -0700
Message-ID: <CADXXVKq3j7Whw9VmE3TAnPM2MkHACx25kk92if_rdFndOcLdbw@mail.gmail.com>
To: "Darrel O'Pry" <darrel.opry@imagescale.co>
Cc: "public-respimg@w3.org" <public-respimg@w3.org>
Hey Darrel.

What is CH-RW exactly? Is it the size the image is intended to be displayed
> at or the width of the browser / device? I read it as the former, which
> made me curious if the browser needs to finish calculating the layout
> before it can begin fetching images?

"Resource Width (RW), is the display width of the requested resource in
density independent pixels on the device."

Meaning, it's the actual size of the image (in dip) in UA's viewport (in JS
speak, it's the .width of the image).

Re, layout: not necessarily / depends on how the width of the asset is
defined. If you look at src-N syntax, it defines image sizes via
<size-viewport-list>, which is with respect to the viewport. Hence, as long
as the viewport size is known (e.g. meta viewport is set), then we don't
necessarily have to wait for full layout. In other words, CH-RW is
implicitly relying on same machinery as src-N.. hence the magic in second
example in src-N interop section [2].


[2] https://github.com/igrigorik/http-client-hints#interaction-with-src-n

> On Thu, Oct 31, 2013 at 5:41 PM, Ilya Grigorik <igrigorik@google.com>wrote:
>> The goal of Client Hints is to automate (where possible) the negotiation
>> of optimal resolution and size of delivered image resources.
>> - For a quick intro: https://github.com/igrigorik/http-client-hints
>> - New v1 draft:
>> https://github.com/igrigorik/http-client-hints/blob/master/draft-grigorik-http-client-hints-01.txt
>> - For server folks (or if you want to see it in action):
>> https://github.com/igrigorik/http-client-hints/tree/master/server
>> With that in mind, a quick overview of differences from previous draft:
>>    - Hints are sent in different headers (e.g. CH-DPR: 2.0) - this
>>    allows better interop with existing caches [1]
>>    - New "server confirmation" header (e.g. "DPR: 1.5") allows server to
>>    indicate the DPR of served resource, which is then used to adjust intrinsic
>>    size calculations on the client. [2]
>>    - "Device width" has been replaced with "Resource display width" (in
>>    DIPs) [3]
>> Also, I've added a section on interop with src-N (see [4]) to demonstrate
>> how CH and src-N can work together to simplify the various RICG use cases.
>> That said, note that the choice of using/not-using either src-N and/or CH
>> is completely up to you. You can combine both and get the benefit of
>> automation of CH + art-direction of src-N, or, you can use src-N for
>> everything, or, you can just use CH to automate resolution switching (viar
>> CH-DPR hint) and resizing (via CH-RW hint).
>> Finally, we have a CH prototype in Chrome that you can play with, check
>> out the instructions here:
>> https://github.com/igrigorik/http-client-hints/tree/master/server#client-hints-clients
>> Feedback, suggestions, questions, etc.. all welcome!
>> ig
>> [1] https://github.com/igrigorik/http-client-hints/issues/14
>> [2] https://github.com/igrigorik/http-client-hints/issues/13
>> [3]
>> https://github.com/igrigorik/http-client-hints/blob/master/draft-grigorik-http-client-hints-01.txt#L239
>> [4] https://github.com/igrigorik/http-client-hints#interaction-with-src-n
> --
> Darrel O'Pry, engineer
> ImageScale.co, Images for the Responsive Web
> http://imagescale.co/#join <http://www.spry-group.com/>
Received on Friday, 1 November 2013 03:22:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:06:10 UTC