New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFP: Client Hints #79

Closed
Jxck opened this Issue Apr 3, 2018 · 18 comments

Comments

Projects
None yet
9 participants
@Jxck
Copy link

Jxck commented Apr 3, 2018

Request for Mozilla Position on an Emerging Web Specification

Other information

@igrigorik

This comment has been minimized.

Copy link

igrigorik commented Apr 3, 2018

Hmm, the httpwg draft appears to be out of date. The latest version is:
https://tools.ietf.org/html/draft-ietf-httpbis-client-hints-05

On a related note, Chrome M67 is shipping Accept-CH + Accept-CH-Lifetime support documented in -05 draft — see blink-dev i2s.

@mnot

This comment has been minimized.

Copy link
Collaborator

mnot commented Apr 3, 2018

@igrigorik Github says that was rebuild an hour ago.

https://github.com/httpwg/http-extensions/tree/gh-pages

@igrigorik

This comment has been minimized.

Copy link

igrigorik commented Apr 3, 2018

@mnot errrr, sorry.. false alarm. I misread the publication date on the httpwg draft. All good!

@annevk

This comment has been minimized.

Copy link
Collaborator

annevk commented Apr 3, 2018

@mnot

This comment has been minimized.

Copy link
Collaborator

mnot commented Apr 3, 2018

To clarify; is this a request for a moz position on Client Hints (the whole spec), or specifically the Accept-CH header? I'm guessing it's the former, in which case the title should be changed.

@martinthomson

This comment has been minimized.

Copy link
Member

martinthomson commented Apr 3, 2018

I think that this needs to be client-hints as a whole. At some point we will need to make decisions separately about whether to send DPR, Save-Data, and friends when a server requests them. That decision might be different for each hint, but right now we are looking to see if the spec is good or bad.

Unfortunately, though I say that we want a position on the entire specification, the answer is bound up in the trade-offs that apply to each of the hints. For mine, DPR is harmless, whereas Save-Data remains fraught for all the reasons that the network information API was tricky. Width and Viewport-Width are close to harmless. I'm inclined toward non-harmful as a whole.

@hsivonen

This comment has been minimized.

Copy link
Member

hsivonen commented Apr 3, 2018

My opinion on Client-Hints hasn't changed from the bug comments.

I can understand why client-hints is easier to bolt onto some legacy systems than more HTML/CSS-oriented solutions, but I still think HTTP is the wrong layer for this, because the hint values can change in situations where re-requesting everything would be undesirable (e.g. rotating a hand-held device or zooming on desktop).

I think the image use case should be handled via <picture> and srcset. I think the CSS use case should be handled via an attribute on <link> to opt out synchronous CSSOM access so that style sheets whose media query isn't currently matching don't need to be eagerly fetched.

I.e. I think our position should be that Client-Hints are harmful. However, if Client-Hints proceeds regardless, Accept-CH is likely non-harmful in the sense that it avoids a situation where browsers would have to keep sending Client-Hints to every site forever just in case some site actually depended on it.

@annevk

This comment has been minimized.

Copy link
Collaborator

annevk commented Apr 3, 2018

I think the CSS use case should be handled via an attribute on <link> to opt out synchronous CSSOM access so that style sheets whose media query isn't currently matching don't need to be eagerly fetched.

FWIW, the HTML Standard allows for this these days and most browsers didn't do this to begin with.

@hsivonen

This comment has been minimized.

Copy link
Member

hsivonen commented Apr 3, 2018

FWIW, the HTML Standard allows for this these days and most browsers didn't do this to begin with.

Do we have a bug open for matching most browsers on the point of CSS loading?

@annevk

This comment has been minimized.

Copy link
Collaborator

annevk commented Apr 3, 2018

@Jxck

This comment has been minimized.

Copy link

Jxck commented Apr 3, 2018

To clarify; is this a request for a moz position on Client Hints (the whole spec), or specifically the Accept-CH header? I'm guessing it's the former, in which case the title should be changed.

I'm asking whole. So I'll change the title.

@Jxck Jxck changed the title RFP: Accept-CH RFP: Client Hints Apr 3, 2018

@bzbarsky

This comment has been minimized.

Copy link
Collaborator

bzbarsky commented Apr 3, 2018

FWIW, the HTML Standard allows for this these days and most browsers didn't do this to begin with.

@annevk, you and @hsivonen are talking about different things. You're talking about whether the fetch blocks rendering. He's talking about whether the fetch happens at all.

@igrigorik

This comment has been minimized.

Copy link

igrigorik commented Apr 10, 2018

I can understand why client-hints is easier to bolt onto some legacy systems than more HTML/CSS-oriented solutions, but I still think HTTP is the wrong layer for this, because the hint values can change in situations where re-requesting everything would be undesirable (e.g. rotating a hand-held device or zooming on desktop).

FWIW, contrary to the legacy claim we're seeing a lot of requests and demand for hints on navigation requests to help optimize delivery of new products. As a concrete example, Google Search goes to great lengths to identify client's properties (network, screen size/capabilities, etc) to deliver fast responses to the client. In some markets this means aggressively scaling back and disabling media heavy features, serving completely different HTML powered by a different stack, etc. Ditto for Google Maps, YouTube, and many other non-Google products. The argument for CH is not that you "cannot do this with plain HTML / CSS / JS", but that CH enables a much more efficient route to tackle such use cases — saving a few RTTs on flaky or high-latency connection has significant impact on product.

I think the image use case should be handled via and srcset. I think the CSS use case should be handled via an attribute on to opt out synchronous CSSOM access so that style sheets whose media query isn't currently matching don't need to be eagerly fetched.

I'm with you. I wish every developer and site owner would adopt <picture> and srcset, religiously optimize all of their assets with optimal quality settings, scale them to display size, and transcode them to relevant optimal image formats. Alas, that is not true today, and I have little faith that this will ever going to happen — I've spent last half decade trying to convince developers to do so, mostly unsuccessfully. In addition to the markup solutions ("the advanced mode") we need to pave paths that allow for simple automation of these best practices, which is the niche that CH aims to fill.

@Jxck

This comment has been minimized.

Copy link

Jxck commented Apr 12, 2018

I think that who choose "which contents will fits for the client" should CLIENT not SERVER.
for example, client send "I'm on wifi", but that's doesn't mean server can serve large content to that client.
if server returns large content for wifi hints and that (seems) works for now, but imagine future if mobile has new candidate about network status, and user doesn't wanna large contents on wifi.
I think mobile browser will send different value to server even if they on wifi. that's the similar thing happens on User-Agent. same for other hints DPR and Width etc.

again, server can't decide which content is fits for client, even if clients sends piece of state information.
if server decide choice of contents based of CH, client will send lie to CH if they wanna other choice from server does. and CH header will be useless.
It seems better to send choice of candidate from server, and client should choice which is fits, like Picture/srcset.

@igrigorik

This comment has been minimized.

Copy link

igrigorik commented Apr 12, 2018

@Jxck you're making same argument as @hsivonen. I agree that there are tradeoffs when the server makes the decision vs. the client, however this is not a binary "good or bad pattern" discussion. There are cases where deferring decision to the server leads to a better outcome for the user, and yes in some cases the application may need to provide a way for the user to override server's decision — this is nothing new, many applications already do this.

As a concrete example, the Google Search App serves a very different experience when the server detects certain client properties, and that has huge lift on user experience (e.g. as in, the user is actually able to see the results), but delivering same experience on the web is pure guesswork (with much lower success rate) today without cooperation from the client — i.e. they need Client Hints.

@Jxck

This comment has been minimized.

Copy link

Jxck commented Apr 13, 2018

@igrigorik

application may need to provide a way for the user to override server's decision

this seems saying lie on CH.

many applications already do this

give me some example which kind of application ?

@igrigorik

This comment has been minimized.

Copy link

igrigorik commented Apr 13, 2018

A simple example is weblight..

Google shows faster, lighter pages to people searching on slow mobile connections in selected countries. To do this, we transcode (convert) web pages on the fly into a version optimized for slow networks, so that these pages load faster while saving data.

image

Same logic applies to Search pages themselves, etc.

@dbaron dbaron added the ietf label Aug 9, 2018

@adamroach

This comment has been minimized.

Copy link
Collaborator

adamroach commented Dec 13, 2018

I've read through the comments above, the comments on Bug 935216, the discussion on dev-platform, and refreshed my memory on the WHATWG objections to conneg. While there is no clear consensus about overall merit, the following appears to be generally true:

  • Architecturally, we prefer client-side solutions for retrieving alternate versions of content, such as <picture>.
  • Despite these architectural preferences, we find that Client-Hints do not present a concrete harm to the web or to its users.

Based on the foregoing, I agree with @martinthomson's evaluation that Mozilla considers this specification to be non-harmful.

adamroach added a commit that referenced this issue Dec 13, 2018

Adding client-hints
Conclusion based on discussion in Issue #79

@adamroach adamroach closed this Dec 14, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment