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: Sat, 2 Nov 2013 10:14:30 -0700
Message-ID: <CADXXVKpBu7JYwMrgnoCqiqSU2AMe+tr3+RnUzNseR0YKOS=RMw@mail.gmail.com>
To: "Darrel O'Pry" <darrel.opry@imagescale.co>
Cc: "public-respimg@w3.org" <public-respimg@w3.org>
On Fri, Nov 1, 2013 at 9:32 PM, Darrel O'Pry <darrel.opry@imagescale.co>wrote:

> 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?

src-N is not a requirement, it just makes it easier because it asks you to
specify image widths with respect to the viewport size. If that information
is not available, then the value is not available until layout is done -
for obvious reasons, this is suboptimal. I am, in large part, counting on
src-N... if that doesn't pan out, then we can revisit the RW hint.

(In the meantime, we still have the full power of CH-DPR...)

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?

No, I don't believe src-N is reaching any further than img (nor should it).
Arguably, it would great to have a RW hint on video, but same challenge..
need to wait for layout, which may, or may not be acceptable. IFrames get
even more tricky.. And elements that don't have a display width (e.g.
script) should arguably be omitted altogether.


> 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 17:15:37 UTC

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