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

James Graham jgraham at opera.com
Tue Feb 7 01:28:24 PST 2012


On 02/06/2012 11:05 PM, Boris Zbarsky wrote:
> On 2/6/12 3:20 PM, James Graham wrote:
>> 1) Same URL structure as the main site
>
> OK, makes sense.
>
>> 2) Less (only citical) information on each screen
>
> Why not do this for the "desktop" version as well?
>
> Alternately, if it's nice to see the information at a glance on desktop,
> why not make the UI such that this information is at the top in both
> versions and the less-critical information is effectively below the fold
> on mobile? I realize that this may be more work and that there may be
> other constraints here, but it seems like that would be ideal in this
> situation.

This basically amounts to "the requirements were wrong". Since the same 
developer made both the desktop and mobile frontends and he is one of 
the major users of the system, and the mobile frontend was purely 
scratching his own itch, I find it very difficult to justify the 
position that he ought to have wanted something different to what he 
actually wanted and made.

In general the idea that sites/applications should be essentially the 
same, but perhaps slightly rearranged, regardless of the device they run 
on just doesn't seem to be something that the market agrees with. It 
seems to me that we can either pretend that this isn't true, and watch 
as platform-specific apps become increasingly entrenched, or work out 
ways to make the UX on sites that target multiple types of hardware as 
good as possible.

>> 3) No looking up / transfering information that would later be thrown
>> away
>
> Again, this seems to apply to desktop as well.

Of course. The critical point was that there was different information 
in the two cases. The unacceptable solution here would have been to 
compute the union of all possible information required but only display 
the relevant subset.

>> 4) Fast => No extra round trip to report device properties
>
> Agreed that this is desirable.

This is the only property that is currently hard to achieve in 
conjunction with the others. If one gives up this requirement one can 
simply download a minimal framework, detect whatever device properties 
you like through the DOM and then pull down the rest of the site. The 
only problem is that this introduces — possibly significant — extra 
latency. One can avoid this by browser sniffing. Which never causes 
problems. Obviously.

So it seems to me that we have a problem that real people are hacking 
their way around by using techniques that are known to be suboptimal or 
downright harmful. Therefore we should take the desire for a solution 
seriously, even though I agree that sending the device screen size, or 
some sort of nebulous "device class" in the HTTP header isn't good enough.



More information about the whatwg mailing list