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

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

From: Darrel O'Pry <darrel.opry@imagescale.co>
Date: Sat, 2 Nov 2013 00:32:40 -0400
Message-ID: <CAGfUJnPf2nciVah-7dpO5_WOnQ8=ou+25zHPE1yHOiGLc6+_RA@mail.gmail.com>
To: Ilya Grigorik <igrigorik@google.com>
Cc: "public-respimg@w3.org" <public-respimg@w3.org>
How could this version of Client Hints be implemented if src-n isn't
adopted or another client spec were to be introduced? How would CH-RW be
calculated in that case? These thoughts came to mind thinking of elements
without src-N attributes, such as /video/source[@src], /iframe[@src],
/script[@source], etc. Will CH-RW be applicable to these elements or is
src-N expected to be a wider ranging practice to replace src in general?


On Fri, Nov 1, 2013 at 11:54 AM, Ilya Grigorik <igrigorik@google.com> wrote:

>
> On Thu, Oct 31, 2013 at 9:04 PM, Darrel O'Pry <darrel.opry@imagescale.co>wrote:
>
>> I was confused from reading the spec about whether each hint was an
>> individual HTTP Header. The README.md clarified that for me. I was under
>> the impression there was still a Client-Hints: header with multiple values
>> inside it for the hints. I like individual headers, they are much more for
>> Vary and managing intermediate caches.
>>
>
> Yep.
>
>
>>  What would CH-RW be populated with for a non-image request, viewport
>> width? Are there usages for these client hints beyond the image use cases?
>>
>
> Great question, TBD. We started discussing this in [1] and I broke it out
> into a separate issue [2]. If you have any thoughts or suggestions, let me
> know (or even better, leave a comment on GH bug :)).
>
> ig
>
> [1] https://github.com/igrigorik/http-client-hints/issues/3 (scroll
> towards the end...)
> [2] https://github.com/igrigorik/http-client-hints/issues/18
>



-- 
Darrel O'Pry, engineer
ImageScale.co, Images for the Responsive Web
http://imagescale.co/#join <http://www.spry-group.com/>
Received on Saturday, 2 November 2013 04:33:27 UTC

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