RE: Media Queries and optimizing what data gets transferred

> From: ilya@igvita.com
> Date: Wed, 30 Jan 2013 07:55:39 +0900
...
> Henri, I believe we're going in circles at this point. 
>
> As a quick summary: > 
> (1) I'm all for markup based solutions. 

Your proposal excludes client side adaptation.  Images deserve their own specific support and perhaps we could all refocus on them.  There are some paths forward such as separating the image resolution choice from the art direction.  Perhaps HTML support could be added if necessary so that the resource selection algorithm that you want to implement on the server side could be rewritten into the HTML by the CDN for delivery to the client?

> (2) Your "nolive" proposal doesn't actually address what I'm after, as several others have already pointed out. 

There seem to be good proposals to address the style sheet loading issue.

> (4) Even if we have (1), and we don't, this is not an argument against HTTP negotiation. There is a time and place for both.

They are exclusive.  Your proposal depends on a 'secret' algorithm in the server/CDN that chooses the resource and the client loses control and this limits client side innovation.

> (5) Cache "fragmentation", whether based on unique URLs or on Vary is the same - stuffing parameters into URLs doesn't magically increase cache hit-rates. 

No one has suggested URL query parameters.   If the client knows which resources are available and can make the choice then only these distinct choices need to be cached.  With client-hints, any change to the client-hints invalidate the cache.  This is a significant difference.  If there are only two image resources to choose from it is technically inferior to key on a much larger input parameter set.   Further the client can be smarter than the cache, and decide to scale down an image already on hand to fit, or to get by with an existing image, rather then blindly re-validating when hint parameters change.



> (6) We can't rely on cookies.
> (7) You shouldn't have to buy a commercial database to perform content adaptation.

Perhaps there are other approaches that are compatible with client side adaptation.
 

In your proposal, server negotiation involves putting data in a

request header. How would the browser's HTTP stack have more

information than its preload scanners, etc.?

> HTTP requests are scheduled by the preloader. 

You had claimed that the client hints header could have more useful state than the browser would have on hand to decide which resource to load, and you have been called out on this and have not addressed this?
 



I think the argument that's bogus is saying that Vary makes stuff

cache-friendly if what it ends up doing is making cache entries

practically never valid without checking with the origin server.
> Lookup the difference between maxage and revalidation. I think therein lies our disconnect. Vary does not force revalidation on every request.

There has been no claim that Vary forces re-validation.  It informs the cache to check the client hints header, and if this has changed then the resource must be re-validated.


 Well, obviously, since the client-side functionality is not there at
present. Your solution is not there currently, either. That sites are

using the option(s) currently available to them is no proof that your

currently non-deployed solution that is similar to the currently

available solution is better than and different presently non-deployed

solution.

> I have already run the proposal by half a dozen CDN vendors - they're all interested in leveraging it, assuming the browser is able to provide the hint.

They have a business interest in gaining more control and being able to offer more value added services, even if it compromises the web.

If you could have sold it to users to enhance their browsing experience then I am sure you would have.
  ...

"You don't need to use it" does not refute the learnability argument.
If there are more solutions to choose from, you need to learn about

them in order to make the choice what not to use.

> That's not an argument, it's your opinion. If you don't want to leverage HTTP negotiation, don't.

With the client hints proposal users lose choice.   A more inclusive solution is likely available and would be preferred from the users perspective.

cheers
Fred