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

false.

ig

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

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:04 GMT