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

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

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Mon, 06 Feb 2012 12:04:08 -0500
Message-ID: <4F300808.4060302@mit.edu>
On 2/6/12 11:42 AM, James Graham wrote:
> No, but there is a different *typical* screen size/resolution for
> mobile/tablet/desktop/tv and it is common to deliver different content
> in each of these scenarios. Although people could load the same site on
> desktop and mobile set up to have the same viewport dimensions, it is
> not that probable and, only one of the two is likely to be resized.

It's very probable that a "mobile" or "tablet" screen will be zoomed in 
various ways.  People do this all the time.

> A typical thing that people want to do is to deliver and display *less*
> content in small (measured in arcseconds) screen scenarios.

This assumes that the entire page is onscreen at once, which is a pretty 
bad assumption for said scenarios.

I feel like I must be missing something pretty fundamental here.  Either 
said "people" are assuming users never use zoom-and-pan type controls on 
their devices or there's something more complicated going on.  What am I 
missing?

> I am sympathetic to the view that it would be desirable to be able to minimise the cost
> of generating a reduced-functionality page without burning the savings
> on extra round trips.

Sure.  I'm not entirely sure how sympathetic I am to the need to produce 
"reduced-functionality" pages...  The examples I've encountered have 
mostly been in one of three buckets:

1) "Why isn't the desktop version just like this vastly better mobile one?"
2) "The mobile version has a completely different workflow necessitating 
a different url structure, not just different images and CSS"
3) "We'll randomly lock you out of features even though your browser and 
device can handle them just fine"

-Boris
Received on Monday, 6 February 2012 09:04:08 UTC

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