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

RE: Media Queries and optimizing what data gets transferred

From: Fred Andrews <fredandw@live.com>
Date: Fri, 1 Feb 2013 12:35:50 +0000
Message-ID: <BLU002-W157669DC82BC29B8C0C5D05AA1C0@phx.gbl>
To: Rob Crowther <robertc@boogdesign.com>, "www-style@w3.org" <www-style@w3.org>
Users that want to choose lower resolution images to speed loads and 
lower bandwidth usage will need to expose some state, but less state 
needs to be exposed with client-side adaptation and the state that is 
exposed is less meaningful.  

The client-hints proposal requires a larger amount of client state to be exposed and processes this on the server side to select from an expected limited range of resources.  Keeping the selection algorithm on the client side inherently reduces the amount of state exposed.  It would be expected that in the majority of cases there is only a single resource to select, and in this case the client-side adaptation need not expose any state whereas with the client-hints proposal the client is require to blindly expose the state in the hope that the server might be able to choose a 'optimal' resource.

Further the client need not base the resource choice on actual device state, so the exposed state is potentially less meaningful.  For example with client-side adaptation the client could choose to download only the largest images and to downscale these as needed.  This would stop re-validation events when media parameters change, further lowering the exposed state.  For example if a client downloads lower resolution images it might match a device characteristic or it might be an arbitrary choice of the user.


> Date: Fri, 1 Feb 2013 11:58:39 +0000
> From: robertc@boogdesign.com
> To: www-style@w3.org
> Subject: Re: Media Queries and optimizing what data gets transferred
> On 01/02/2013 06:37, Fred Andrews wrote:
> > Keeping the adaptation client-side avoids the user
> > being forced to reveal UA state
> Surely the client-state is going to be revealed by what resources it 
> downloads anyway?
> Rob
Received on Friday, 1 February 2013 12:36:17 UTC

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