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

[whatwg] RWD Heaven: if browsers reported device capabilities in a request header (Boris Zbarsky)

From: Ashley Sheridan <ash@ashleysheridan.co.uk>
Date: Mon, 06 Feb 2012 22:21:30 +0000
Message-ID: <1328566890.2643.16.camel@localhost.localdomain>
On Mon, 2012-02-06 at 22:16 +0000, Kornel Lesi?ski wrote:

> On Mon, 06 Feb 2012 20:00:45 -0000, Irakli Nadareishvili  
> <irakli at gmail.com> wrote:
> 
> > 1. Adaptive images:
> > To optimize user-experience on smart-phones (most of which have  
> > relatively small screens, and are on slow connections most of the time)
> 
> Be careful with generalizations like that.
> 
> Mobile devices can be connected to high-speed networks. Laptops can be  
> tethered via mobile networks.
> 
> There are many permutations of screen size, DPI, zoom, network speed,  
> bandwidth cost and memory availability that influence decision what image  
> resolution is best, and it's not as simple as "mobile" vs "non-mobile".
> 
> 
> There aren't even clear "device classes". Basic device characteristics  
> like physical screen size and presence of a hardware keyboard can change  
> dynamically!
> 
> Smartphones can be connected to TVs and projectors. Tablets can be  
> connected to keyboards. Laptops can be flipped into tablet mode. Desktops  
> can have touchscreens ? and these aren't obscure things. It's iPad with  
> AirPlay and dock. It's most tablet PCs. You can expect many laptops to  
> have touchscreens soon.
> 
> "Mobile" or "smartphone" can mean anything from Opera Mini on GPRS  
> connection to a quad-core 4G smartphones more powerful than desktops were  
> few years ago.
> 
> 
> I appreciate optimisations you're trying to make, but simply reporting  
> basic capabilities in an HTTP header isn't going to work well in other  
> than few most common cases.
> 
> I hope we could come up with a better solution that can all the  
> optimisations and improved experience you want to achieve, but doesn't  
> have pitfalls of assuming that slow networks and touch screens go  
> hand-in-hand, or that devices with keyboards also have mouse and < 100dpi  
> screen, etc.
> 
> 
> > 2. Adaptive CSS/Javascript.
> 
> CSS has media queries already. New queries can (and I think should) be  
> added to query more capabilities like presence of a touch screen (Mozilla  
> experiments with -moz-touch-enabled media query already).
> 
> Media queries are dynamic and can be observed by JavaScript, so when you  
> switch from tablet's own touch screen to an external display, pages could  
> theoretically switch UI too.
> 
> > If server could easily detect device type/capabilities it would have the  
> > ability to tailor aggregated js/css files to a class of a device, thus  
> > providing greatly improved experience.
> 
> Sure, but it doesn't mean that the server has to do that and that it's the  
> only way to do that. For example:
> 
> <script src=touch-ui.js media="input-type: touch">
> <script src=mouse-ui.js media="input-type: mouse">
> 
> (although I'm not suggesting using that form literally, as it has some  
> drawbacks of its own)
> 
> Next version of JavaScript is going to have modules, which makes loading  
> of JavaScript cleaner than <script>. Perhaps modules could be loaded  
> conditionally based on media-query-like declarations?
> 


I can't remember where right now, but I do recall seeing an article
which said that it was a common misconception that mobile devices were
most often on a slow connection. Personally, I tend to make most use of
my mobile for browsing when I'm on a wireless connection. Just because
someone is using a mobile device, it doesn't naturally mean they are on
the move.
-- 
Thanks,
Ash
http://www.ashleysheridan.co.uk
Received on Monday, 6 February 2012 14:21:30 UTC

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