Spec
http://tools.ietf.org/html/draft-grigorik-http-client-hints-00
Summary
New device form factors and screen DPRs are added to the market on a regular basis. Serving the same image resources to all devices (which may display them in differing dimensions and at different DPRs) is wasteful, and hurts Web performance.
This feature will allow the server to automatically pick and serve the best available resolution file without requiring any changes in the CSS or HTML markup of the page (hands-on example with nginx).
Compatibility Risk
Low. This is a new feature. If the client does not support or advertise CH, or if the server does not support it, regular image (as implemented today) is served.
Ongoing technical constraints
None.
Is this feature supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?
Row on feature dashboard?
Yes.
Are any other browsers implementing this feature?
Are any other browsers implementing this feature?
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
> When I zoom in by 110% on desktop Chrome (running on Windows), I seeIdeally it should use the same value as window.devicePixelRatio. We
> window.devicePixelRatio reported as 1.100000023841858. Should that exact
> value be sent in the "CH: dpr=" HTTP request header?
might want to round it to a couple of decimal points though.
On Fri, Sep 6, 2013 at 7:57 PM, Darin Fisher <da...@chromium.org> wrote:Given http://wiki.whatwg.org/wiki/Why_not_conneg I don't think this
> Are any other browsers implementing this feature?
will work out. Content negotiation works in environments where you
control both client and server and intermediaries don't get in the
way, otherwise it's just a mess.
ig
Which properties? Are these all HTTPS based? Would love to know how successful content negotiation is in the clear. And I am curious how much of this is a property of the specific axis of content negotiation. We've had some amount of difficulty in the past with A-E.
But Ilya says it's not just Google servers. For example, CDNConnect http://blog.netdna.com/developer/how-to-reduce-image-size-with-webp-automagically/. I think it's unfair to claim that "you control both client and server" in this case, unless I'm missing something.And, if I understand correctly, the content negotiation here is being done with the new Client-Hints header. I think using a new header has significantly lower risk of intermediaries barfing on it, since people use new headers all the time, so the default intermediary behavior is to ignore it.
This reminds me that unless we really want C-H to only ever contain one hint, we really need to finish up the HTTP Key work (http://tools.ietf.org/html/draft-fielding-http-key-00).