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

[Matthew Wilcox]

Thanks for the feedback :)

I've replied inline, but please be aware that I don't have a browser-vendor
hat to put on so some of my questions may well be a bit naive (for which I
apologise in advance)

On 7 February 2012 17:11, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> On 2/7/12 9:13 AM, Matthew Wilcox wrote:
>
>> To be clear: this is a case of browser vendors deciding it's too
>> expensive and therefor not allowing it to be implemented
>>
>
> This is a case of browser vendors (or at least me with my browser
> implementor had on) thinking that sending this sort of information will
> hurt their users' privacy


Can you clarify how this hurts privacy? I'm not sure how reporting back
things like connection speed or screen size constitutes a genuine privacy
issue?


> , will cause their users to get more broken pages (which is what happens
> in many cases with browser sniffing right now), will lock new devices out
> of the market (which is what happens with new UA strings right now).  And
> hence that the proposal is bad for the web in various ways.
>

I'm not sure what your grounds are for thinking this. Would it not be
sensible for the server to have to serve some default if the headers aren't
there anyway, the assumption must be that the device can't send these
headers. In what circumstances might this cause breakages? And how could it
possibly lock out any devices? This is a progressive-enhancement type tech,
not a "if you don't have the ability to notify the server you can't get any
info" type tech. Surely?


> Now obviously it's also good for the web in various ways, if people use
> the information "correctly" and such.  My faith in this is somewhat
> tarnished by the fact that every concrete proposal for using it that I've
> seen seems to be broken by design, which means that chances of anyone using
> it "correctly" are vanishingly small.


Can you tell us how they're broken so we can fix it?


>  We should strive to provide information that will enable the server to
> better serve the user without it being rocket science to do so without
> breaking other users.


Absolutely agree, but I don't see how a server requesting and then getting
a header is rocket sceince. Especially if the current solution is to
connect to some massive device database to query potential points of
reference and then act accordingly.


>  when it should be
>> authors in the position to know whether it's too expensive given their
>> specific use case.
>>
>
> This is privileging authors over users. I understand the author
> perspective on this, but in general I care about users more than we do
> about authors....  I don't think I'm the only one.


I can see your point, but there isn't any impact for users unless the
author has "opted in" and requested headers. Right? The defaults are
"server gets no headers". Put it another way - how can an author tailor
things for a user if the user isn't able to report anything to the server?
Not allowing this process is a disservice to the user *and* the author.
It's basically saying "no, you can't drive the car because you may end up
on a busy road which will be even slower than walking".


>  No offense taken btw. Things have to prove themselves. The danger is the
>> standards process is too slow to react well, and some even more hacky
>> solution turning into a de-facto standard.
>>
>
> Yes, this is a problem.
>
>
>  Devices of significantly varied size and performance are here to stay
>>
>
> Yes, but "size" and "performance" are not necessarily a function of the
> actual device.  They can be a function of the device, the network, the
> currently attached peripherals, etc.  Importantly, they are not
> time-invariant.  The question is what we can do about that...
>

Agreed - which is *exactly* why I think headers are the only viable
solution. The other solutions operate by detecting the device and making
assumptions about those variables based on the device specifications. Only
the device you're talking with right then can possibly have that
information.


> (Simple example: the performance of my laptop will vary by easily a factor
> of close to 1.5 just depending on whether it's plugged in and what sort of
> surface it's resting on.  I expect this trend to continue unless we get
> some sort of revolutionary improvements in battery and cooling technology.)


Exactly! Hence the need for the browser to report *as a header* with each
request what the current values are for those variables.


> -Boris