Intent to (re-)implement - Client Hints

115 views
Skip to first unread message

Yoav Weiss

unread,
Feb 17, 2015, 3:08:09 AM2/17/15
to blink-dev

Contact emails

Spec

Summary
Client-Hints is a standard destined to improve content negotiation between the browser and the server, and enable the browser to advertise various characteristics to the server along with resource requests, so that the server can adapt its responses to these characteristics in a cache friendly way.

Motivation
In some scenarios, markup-based responsive images solutions come with their own costs: the requirement to modify and update all existing pages may be extremely expensive for legacy web sites, and some developers may prefer to keep image optimization outside of markup and handle it in lower layers or through RESTful means, via content-negotiation. Client-Hints can provide that.
More details here.

There's already an existing partial implementation of an older version of the spec (which covers DPR only). I plan to overhaul that implementation and move it from being mostly on the chrome side to the Blink side. That would make the dynamic aspects of the spec (the RW hint) significantly easier to implement.

Compatibility Risk
Low. The solution is based on HTTP negotiation, allowing servers to opt-in to the signals they want to receive from the client, and client is in full control on deciding which signals it wants to send for each request.
As a result, servers cannot rely on a specific hint being sent from the client, so non-supporting browsers won't experience compatibility issues. Also - there's very little to no overhead for sites that don't choose to use CH.

Signals from other browser vendors
Firefox: Positive & negative signals. I believe the positive outweighs the negative.
Safari: No public signals.

Ongoing technical constraints
None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.

OWP launch tracking bug?

Link to entry on the feature dashboard

Requesting approval to ship?
Not just yet.

Philip Jägenstedt

unread,
Feb 27, 2015, 3:26:24 AM2/27/15
to Yoav Weiss, blink-dev
No LGTM needed, but experimenting with this does sound good to me.

The document you linked to is really helpful, some questions:

It sounds like not modifying markup is a big deal. For pages that don't specify image width and height, is there any way with this proposal to upgrade to hires images while keeping the same size on the images? (I would assume not.)

I'd also be curious to hear what people involved with ServiceWorker say about the paragraph explaining why "some hints cannot be implemented with ServiceWorker." Is there any change to ServiceWorker or other APIs that would make it possible to implement something similar to Client Hints? (Sorry if this is a stupid question, I didn't look very hard for an answer.)

Philip

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Yoav Weiss

unread,
Feb 27, 2015, 3:41:25 AM2/27/15
to Philip Jägenstedt, blink-dev
On Fri, Feb 27, 2015 at 9:26 AM, Philip Jägenstedt <phi...@opera.com> wrote:
No LGTM needed, but experimenting with this does sound good to me.
Great :)
 

The document you linked to is really helpful, some questions:

It sounds like not modifying markup is a big deal. For pages that don't specify image width and height, is there any way with this proposal to upgrade to hires images while keeping the same size on the images? (I would assume not.)

Yes. The Content-DPR response header enables just that. It enables the server to control the intrinsic dimensions the browser would take into account when displaying the image resource served.
 

I'd also be curious to hear what people involved with ServiceWorker say about the paragraph explaining why "some hints cannot be implemented with ServiceWorker." Is there any change to ServiceWorker or other APIs that would make it possible to implement something similar to Client Hints? (Sorry if this is a stupid question, I didn't look very hard for an answer.)

Some hints (specifically the "RW" or "resource width" hint) require per-resource info. Implementing that in Service-Worker would require either SW having full visibility into the DOM-tree and Render-tree, or having the main document message it all that info, which is extremely cumbersome at best.
Reply all
Reply to author
Forward
0 new messages