Re: Media Queries and optimizing what data gets transferred

> > (1) I'm all for markup based solutions.
>
> Your proposal excludes client side adaptation.
>

sigh! It doesn't. Don't enable the server feature, or don't opt in, or
provide properly sized images. Done deal.


> > (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.
>

See above. Don't enable it on your server if you don't want it. Opt out...
err, I'm repeating myself.


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

??? The header obviously can't have "more knowledge" than the browser,
since the browser is the one creating the header - they have the same
knowledge. What the header enables is for the server to assist the browser
to pick the best resource.


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

Great, then we're in agreement. Users want to pay to solve a problem,
others are willing to offer the service.  Everyone wins. If *you* don't
want it on your site, then don't enable it. And by the way, you don't have
to pay, you can install an open source solution.


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

false.

ig

P.S. Once again, we're going in circles.