- From: Darrel O'Pry <darrel.opry@imagescale.co>
- Date: Sat, 2 Nov 2013 00:32:40 -0400
- To: Ilya Grigorik <igrigorik@google.com>
- Cc: "public-respimg@w3.org" <public-respimg@w3.org>
- Message-ID: <CAGfUJnPf2nciVah-7dpO5_WOnQ8=ou+25zHPE1yHOiGLc6+_RA@mail.gmail.com>
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