W3C home > Mailing lists > Public > www-style@w3.org > January 2013

Re: Media Queries and optimizing what data gets transferred

From: Ilya Grigorik <ilya@igvita.com>
Date: Wed, 30 Jan 2013 21:36:12 +0900
Message-ID: <CAKRe7JExQFfb9-gYiq3VrU0ye9kp95wtvL3f29kmvP5H4c5ETg@mail.gmail.com>
To: Fred Andrews <fredandw@live.com>
Cc: "www-style@w3.org" <www-style@w3.org>
> > (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.



P.S. Once again, we're going in circles.
Received on Wednesday, 30 January 2013 12:37:22 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:07 UTC