Re: [whatwg] Bandwidth media queries

On Mon, 21 May 2012, Mounir Lamouri wrote:

> On 05/21/2012 04:34 PM, Boris Zbarsky wrote:
>> On 5/21/12 10:09 AM, Mounir Lamouri wrote:
>>> On 05/20/2012 03:04 PM, Boris Zbarsky wrote:
>>>> On 5/20/12 5:45 AM, Paul Irish wrote:
>>>>> Since no one mentioned it, I just wanted to make sure this thread is
>>>>> aware
>>>>> of the Network Information API [1], which provides
>>>>> navigator.connection.bandwidth
>>>>>
>>>>> It's been recently implemented (to some degree) in both Mozilla [2] and
>>>>> Webkit [3].
>>>>
>>>> As far as I can tell, the Mozilla implementation always returns Infinity
>>>> for .bandwidth.
>>>
>>> This is not true. There is an implementation for Firefox Android which
>>> is based on the connection type.
>>
>> Ah, indeed.  I had missed that codepath.
>>
>> If I'm reading the right code now, that looks like it returns a constant
>> value for each connection type (e.g. if you're connected via Ethernet or
>> Wifi it returns 20; if you're connected via EDGE it returns 0.2, etc).
>
> The idea is that the specification allows the implementation to be
> trivial and improve without changing the specification.

That seems incredibly unlikely to work in practice. Early implementations 
will return 20 or 0.2 and sites will do

if (bandwidth == 20) {
   //get high quality site
} else {
   //get simplified site
}

and users will be very surprised when upgrading their browser causes them 
to get the simplified site or low quality assets when before they never 
did.

> And that
> implementation is good enough for web pages to know if the user is in a
> slow or fast connection without giving the connection type and leaking
> information.

I think the fundamental problem with this API isn't that it might leak 
information, it's that it's that it is quite likely to make the overall 
user experience worse rather than better. It is also extremely difficult 
to implement in a really good way as evidenced by the fact that all the 
"implementations" so far are extremely half-hearted.

Received on Monday, 21 May 2012 20:09:12 UTC