W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2012

[whatwg] RWD Heaven: if browsers reported device capabilities in a request header

From: Kornel Lesiński <kornel@geekhood.net>
Date: Tue, 07 Feb 2012 23:28:22 -0000
Message-ID: <op.v9b0tkkqte2ec8@aimac.local>
On Tue, 07 Feb 2012 21:17:22 -0000, divya manian <divya.manian at gmail.com>  
wrote:

> This is the info I would love to see any time for my app to make the
> kind of decision it should:
> * connection speed: so I know how fast my resources can load, how  
> quickly.
> * bandwidth caps: so I know I shouldn't be sending HD images.
> * battery time: network requests are a drain on battery life, if I
> know before hand, I can make sure the user gets information in time.

I understand you'd like to provide most appropriate images, but why do  
*you* have to exactly decide which is used when? Everybody is going to  
make basically same decisions: if network is slow, use smaller image. If  
network is fast and device is high-DPI, use larger image, etc.

So instead of requiring every server to reinvent essentially the same  
logic, why not have it in the browser? Browsers can query all the details  
of the system without any privacy risks or network overheads.

You could just say "I've got these image sizes available, choose which one  
suits you best", and browser would pick one that makes most sense. You  
(and every other web developer) wouldn't have to write and maintain code  
for computation of bandwidth/latency/battery/screen size/density/zoom/cpu  
speed/memory tradeoffs. With so many variables I'm afraid that average  
developer wouldn't make better choices than mobile browsers themselves can.

> * notification of change of any of these: so I can provide scaled up
> experiences when these alter.

With HTTP that would require browser to re-send requests for the page and  
assets just in case server would make a different decision, and if  
difference wasn't big enough to change server's decision, then energy to  
wake up cell radio and bandwidth to send requests would be wasted (e.g.  
cost of keeping server informed about often-changing zoom level could  
easily outweigh savings from reduced images).

OTOH if client was given information on what variants of resources are  
available, then it could cheaply re-check conditions when cell radio is  
off and only connect when necessary and only request files that have  
changed substantially.

-- 
regards, Kornel Lesi?ski
Received on Tuesday, 7 February 2012 15:28:22 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:39 UTC