Re: [whatwg] Bandwidth media queries

[James Graham]

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.

Re: [whatwg] Bandwidth media queries

[Mounir Lamouri]

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. 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. That would require not returning exact constant by blurring
them a bit. This is not done yet but could easily happen.

--
Mounir

Re: [whatwg] Bandwidth media queries

[Mounir Lamouri]

On 05/21/2012 04:42 PM, James Graham wrote:
> On 05/21/2012 04:34 PM, Boris Zbarsky wrote:
>> 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).
> 
> This suggests that the API is extremely silly; although one could
> presumably claim that "an estimate" allows one to return anything, I
> don't see how returning "20" if the server is feeding you 1 byte/second
> can be helpful to anyone. If no one plans to implement this as a loose
> proxy for "type of connection" the spec shouldn't pretend to do more
> than that.
> 
> Can you point me to the discussion of usecases that led to this design?

This has been discussed in the DAP WG [1]. Actually, I think we should
move that discussion there.

[1] http://www.w3.org/2009/dap/

Cheers,
--
Mounir

Re: [whatwg] Bandwidth media queries

[James Graham]

On 05/21/2012 04:50 PM, Boris Zbarsky wrote:

On 5/21/12 10:42 AM, James Graham wrote:

Can you point me to the discussion of usecases that led to this design?


Me personally, no. I wasn't involved in either the spec or the Gecko
impl; I'm just reading the code


Sorry; s/you/anyone/

(I also meant "*except* as a loose proxy for 'type of connection'")

Re: [whatwg] Bandwidth media queries

[Boris Zbarsky]

On 5/21/12 10:42 AM, James Graham wrote:

Can you point me to the discussion of usecases that led to this design?


Me personally, no.  I wasn't involved in either the spec or the Gecko 
impl; I'm just reading the code


-Boris

Re: [whatwg] Bandwidth media queries

[James Graham]

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).


This suggests that the API is extremely silly; although one could 
presumably claim that "an estimate" allows one to return anything, I 
don't see how returning "20" if the server is feeding you 1 byte/second 
can be helpful to anyone. If no one plans to implement this as a loose 
proxy for "type of connection" the spec shouldn't pretend to do more 
than that.


Can you point me to the discussion of usecases that led to this design?

Re: [whatwg] Bandwidth media queries

[Boris Zbarsky]

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).


-Boris

Re: [whatwg] Bandwidth media queries

[Mounir Lamouri]

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.

--
Mounir

Re: [whatwg] Bandwidth media queries

[Henri Sivonen]

On Wed, May 16, 2012 at 9:48 PM, Matthew Wilcox  wrote:
> If you're a browser you are the software interpreting the instructions
> of a given language: CSS in this case.

In addition to the problem that it's actually hard for browsers to
know what the current bandwidth is especially on mobile networks, some
of this responsive design threads assume that the author knows best
when to withdraw content or content quality due to low bandwidth.

>From the user perspective, I think it's not at all clear that users
always prefer to get less content when they are on a slower
connection. Personally, I expect to see "full" content on a slow
connection if I wait for long enough, but it's also annoying to have
to wait for the whole page to load before the page is usable. The
problem is that sometimes waiting is worth it and sometimes it isn't
and the author might not know when the user considers the wait to be
worth it.

Unfortunately, the way the load event works makes it hard to make
pages so that they start working before images are fully loaded and
then keep improving in image quality if the user chooses to wait.
Also, some browsers intentionally limit their own ability to do
incremental rendering both to get better throughput and to get better
perceptual speed in cases where the overall page load is relatively
fast.

On a very slow networks (GPRS or airline Wi-Fi) I think Opera Mini
with *full* image quality provides the best experience: the page
renders with its final layout and becomes interactive with images
replaced with large areas of color that represents the average color
occupying that area in the images. The images then become sharper over
time. Thus, the user has the option to start interacting with the page
right away if the user deems the image is not worth the wait or can
choose to wait if the user expects the images to contain something
important. (This assumes, of course, that the user is not paying per
byte even though the connection is slow, so that it's harmless from
the user perspective to start loading data that the user might dismiss
by navigating away from the page without waiting for the images to
load in full.)

Instead of giving web authors the tools to micro-manage what images
get shown in what quality under various bandwidth conditions, I think
it would be better to enable a load mode in traditional-architecture
(that is, not the Opera Mini thin client architecture) browsers that
would allow early layout and load event and progressive image quality
enhancement after the load event is fired and the page has its final
layout (in the sense of box dimensions). I.e. have a mode where the
load event fires as soon as the everything except images have loaded
and the dimensions of all image boxes are known to the CSS formatter
(and PNG and JPEG progression is used 1990s style after the load even
has fired).

-- 
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

Re: [whatwg] Bandwidth media queries

[Maciej Stachowiak]

On May 20, 2012, at 6:13 AM, Boris Zbarsky  wrote:

> On 5/20/12 9:04 AM, 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.
> 
> Oh, and the WebKit implementation you linked to sometimes returns whatever 
> value the embedding set on the object (thus punting the problem of what to 
> return to the embedding), and by default seems to do this, if I read it right:
> 
> 57unsigned int NetworkInfoClientEfl::bandwidth() const
> 58{
> 59notImplemented();
> 60return 10; // MB/s
> 61}
> 
> (not exactly spec compliant, so much, of course).

Well spotted. That bug is regrettably still in WebKit trunk. 


In addition, the feature is implemented only for a single WebKit port which is 
not one of the most widely used (EFL), and most other functionality of the 
NetworkInformation interface is likewise unimplemented. We may end up removing 
this feature from WebKit if it is not made more functional and/or adopted by 
more ports. It's not clear if the interface is effectively implementable and 
the feature is kind of an experiment at the moment.

Regards,
Maciej

Re: [whatwg] Bandwidth media queries

[James Graham]

On Sun, 20 May 2012, 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.


And this is perfectly compliant, since the spec says:

   The user agent must set the value of the bandwidth attribute to:

   0 if the user is currently offline;
   Infinity if the bandwidth is unknown;
   an estimation of the current bandwidth in MB/s (Megabytes
   per seconds) available for communication with the browsing
   context active document's domain.


If no one is planning on implementing this feature in a meaningful way, 
why is it in the spec?


(yes I know this is not exactly the right list).

Re: [whatwg] Bandwidth media queries

[Boris Zbarsky]

On 5/20/12 9:04 AM, 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.


Oh, and the WebKit implementation you linked to sometimes returns 
whatever value the embedding set on the object (thus punting the problem 
of what to return to the embedding), and by default seems to do this, if 
I read it right:


57  unsigned int NetworkInfoClientEfl::bandwidth() const
58  {
59  notImplemented();
60  return 10; // MB/s
61  }

(not exactly spec compliant, so much, of course).

-Boris

Re: [whatwg] Bandwidth media queries

[Boris Zbarsky]

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.


And this is perfectly compliant, since the spec says:

The user agent must set the value of the bandwidth attribute to:

0 if the user is currently offline;
Infinity if the bandwidth is unknown;
an estimation of the current bandwidth in MB/s (Megabytes
per seconds) available for communication with the browsing
context active document's domain.

-Boris

Re: [whatwg] Bandwidth media queries

[Paul Irish]

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].

[1] http://dvcs.w3.org/hg/dap/raw-file/tip/network-api/index.html
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=677166#c42
[3] http://trac.webkit.org/changeset/112815

Re: [whatwg] Bandwidth media queries

[Matthew Wilcox]

On 18 May 2012 11:17, Kornel Lesiński  wrote:
> I think we may be talking past each other, as I don't see how your answers 
> address the problems I'm trying to highlight.

Indeed, I'm not debating your points - I accept that it isn't
realistically achievable in HTML/CSS :)

All the last comment was doing is pointing out that regardless of
this, people will try to achieve the same effect using JS (and already
are), and will wonder why it's not in HTML/CSS.

Re: [whatwg] Bandwidth media queries

[Kornel Lesi��ski]

I think we may be talking past each other, as I don't see how your answers 
address the problems I'm trying to highlight. 

It's not enough to say it's a hard problem. It's not going to solve itself.

If you say media queries can be useful for bandwidth/quality use-cases, you 
need to actually specify how can they work.

I'm trying to show here that MQ model is very problematic, and won't work well 
*even if UA has perfectly accurate bandwidth information at all times*!

MQs are stateless and expected to match the same way globally, and that clashes 
with stateful and non-uniform nature of caches that should be taken into 
account. 

So please specifically address cases I've listed in my previous email. 


-- 
regards, Kornel


On 18 maj 2012, at 10:52, Matthew Wilcox  wrote:

> Thanks for all the feedback everyone.
> 
> I don't think it's going to stop people trying to do this though;
> there are already write-ups for doing bandwidth detection in JS to
> manipulate  assets:
> http://www.csskarma.com/blog/detecting-for-bandwidth/
> 
> Tricky problem.
>> I'm not sure if that was intended to be an answer to my message:
>> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-May/036005.html
>> 
>> I don't think that's at "decision" stage, because nobody has defined what
>> options are there to decide.
>> 
>> The options I see are not compelling:
>> 
>> 1. let it match actual bandwidth and apply rules according to standard media
>> query logic. This will suck, as the page design will flip and reload
>> whenever wind blows, and cache will be wasted.
>> 
>> 2. let it match some average or "sticky" value of bandwidth according to
>> standard MQ logic. This will suck less, but still it won't make optimal use
>> of cache OR bandwidth, and page may get stuck in suboptimal bandwidth (e.g.
>> you catch WiFi only momentarily and get 3G browser stuck with peak value or
>> vice versa).
>> 
>> 3. Violate MQ logic and allow mixed queries on the page (e.g. if browser has
>> cached image while it had high bandwidth, use the image, even if bandwidth
>> has dropped since). That will allow UAs to use best quality images it can
>> and eliminate redundant requests, but will create unpredictable,
>> inconsistent nightmare for designers.
>> 
>> 
>> That's why I think there needs to be alternative solution parallel to MQs.
>> It's a shame that Respimg mailinglist is dead:
>> 
>> http://lists.w3.org/Archives/Public/public-respimg/2012May/0003.html
>> 
>> --
>> regards, Kornel Lesi��ski

Re: [whatwg] Bandwidth media queries

[Matthew Wilcox]

Cheers for that feedback Andy - it is indeed a complicated issue with
much more nuance than I think many people (myself included) would have
expected. I still think there's a technical solution there, but as you
say - it's making that solution reliable enough to be worth it. The
problem really is "what is reliable enough"? How accurate does it need
to be.

I can understand that this is in practical terms too complex an issue
to be worth the effort required to get something workable.

And the logic isn't simple either. That said, it's only a matter of
making a decision about what to do. The actual mechanics shouldn't be
hard, it's the decision making that is.

Re: [whatwg] Bandwidth media queries

[Kornel Lesiński]

On Wed, 16 May 2012 19:48:04 +0100, Matthew Wilcox  
 wrote:



First off I know that a number of people say this is not possible. I
am not wanting to argue this because I don't have the knowledge to
argue it - but I do want to understand why, and currently I do not.
Please also remember that I can only see this from an authors
perspective as I'm ignorant of the mechanics of how these things work
internally.

The idea is to have something like:





This make an obvious kind of sense to an author.


What would happen in this scenario:

I'm in a cafe with free WiFi browsing on my phone, I have 8mbps bandwidth.  
I open the page and read it (it could be a webapp or a long article that  
stays open for a long time).


I leave the cafe, my bandwidth drops to 1mbps, but I still have the same  
page open.


Should the design change? Should the browser throw away all high-res  
images it has downloaded and re-download them in poor quality?


What when I reload or browse to a next subpage? My browser still has  
high-res images in the cache. Should it now apply low-end design and  
re-download all images in poor quality?


--
regards, Kornel

Re: [whatwg] Bandwidth media queries

[Andy Davies]

Hi Matt,

You really want to know what the throughput is rather than just the
bandwidth and throughput is a bit of a PITA to work out in web
conditions...

Throughput is a mixture of available TCP connection time, bandwidth,
latency and packet loss, etc.

In theory you could measure it from the browser but there are a number
of issues, here are some examples:

A typical webpage is made up of many components, which are retrieved
via short, bursty conversations between the browser and server.

The initial TCP connections go though a 'slow-start' phase while the
client and server determine what's the optimal number of packets that
can be sent without being acknowledged. The number of packets inflight
and the latency effective set a cap on the throughput. So measuring
the resources that are downloaded first would probably under report
the available throughput

Multiple (sub-) domains confuse things further...

Assume you can effectively measure throughput from the first resources
to be downloaded (HTML, CSS etc), what happens if the images are on a
different domain e.g. a CDN? The throughput that's just been measured
isn't applicable to the CDN's domain.

Caching further complicates things as you can't use anything that's in
the cache to measure throughput (or can you?)

Although slightly tangential it's worth having a read of Mike Belshe's
"More Bandwidth Doesn't Matter (Much) -
http://www.belshe.com/2010/05/24/more-bandwidth-doesnt-matter-much/

I'm not sure I'd agree with Tab's comment that authors aren't the best
people to make decisions on what content should appear under different
throughput conditions though. If they aren't I'm not sure who is? If
it's the browser then the author still has to signal their intent to
the browser so they are effectively making the choice.

Cheers

Andy

@andydavies

Re: [whatwg] Bandwidth media queries

[Ashley Sheridan]

On Wed, 2012-05-16 at 20:09 +0100, Matthew Wilcox wrote:

> Ok, so really it's an efficiency of authoring problem; before I just
> didn't get how it'd be any different to a viewport width from the
> perspective of an author.
> 
> That said, when coupled with viewport responses... yeah, that could
> get complicated to author. Essentially each bandwidth bracket would be
> a multiplier for the number of cases you'd need to address.
> 
> Cheers again.
> 
> 
> 
> On 16 May 2012 20:00, Tab Atkins Jr.  wrote:
> > It's not that bandwidth queries aren't possible, it's that they're not
> > *useful* for the things you'd want to use them for, and they don't act
> > like you'd want anyway.
> >
> > I explain much of the reasoning in 
> > - while the blog post purports to be about resolution negotiation, it
> > actually more generally covers why bandwidth queries are a bad idea.
> >
> > In short, bandwidth is often quite variable, particularly on the
> > devices where you'd actually *want* to use this information.  This
> > means the instantaneous bandwidth (what MQ would be using) can easily
> > be useless to you.  It also means that you'll easily and commonly get
> > into perverse situations where trying to be "bandwidth-friendly" ends
> > up downloading *more* data than a naive page would.
> >
> > The author is just not in a good situation to be able to make sound
> > decisions about how to react to bandwidth. You need a lot more
> > information than a MQ can provide, and even if we provided it, the
> > logic necessary to use that information *right* is fairly subtle and
> > definitely not settled.
> >
> > This is why providing facilities for the author to just *tell* the
> > browser about the relative filesizes of things, so it can make its own
> > decisions about which resource to download.  This keeps the language
> > simpler, because we don't have to communicate as much information.  It
> > also centralizes the "what to do" logic into a small number of places
> > (the browsers) where it has a better chance of being right, rather
> > than hoping that thousands or milions of authors all stumble on the
> > best solution together, and keep their pages updated as best-practices
> > change.
> >
> > ~TJ


I've given the bandwidth issue some thought and it's definitely not a
simple problem to solve. The way I see it, you need support at the OS
level. Imagine these (fairly typical) scenarios:

1) A regular laptop computer on a typical home broadband connection
(let's assume enough bandwidth to happily deliver a web page in a decent
time)
2) The same laptop now connected to a work network. Contention ratios
are higher so available bandwidth, although the same as the home one by
spec, is slower because of it being shared so much more
3) Laptop now in a café somewhere tethered to a mobile phone for it's
Internet connection

Each scenario could have quite different average bandwidths, so it's
fairly obvious that any bandwidth monitoring should be done with the
network connection as a profile in mind. OS X and some Linux distros
already offer statistics on the network you're connected to I believe,
and Windows can with helper programs (although I think these only
monitor on a single network interface generally). Some work would need
to be done on algorithms to ensure the average gave a good
representation of the bandwidth, e.g. smoothing out spikes, taking into
account that some websites are generally just really slow to respond,
etc.

On it's own, a browser would find this impossible, because it won't be
able to easily adapt to different situations as I've outlined above.

-- 
Thanks,
Ash
http://www.ashleysheridan.co.uk

Re: [whatwg] Bandwidth media queries

[Matthew Wilcox]

On 16 May 2012 20:10, James Graham  wrote:
> On Wed, 16 May 2012, Matthew Wilcox wrote:
>
>> First off I know that a number of people say this is not possible. I
>> am not wanting to argue this because I don't have the knowledge to
>> argue it - but I do want to understand why, and currently I do not.
>> Please also remember that I can only see this from an authors
>> perspective as I'm ignorant of the mechanics of how these things work
>> internally.
>>
>> The idea is to have something like:
>>
>> 
>> 
>> 
>
>
> Without going deeper into the specific points, implementation experience
> suggests that even implementing a binary low-bandwidth/high bandwidth
> detection is extremely difficult; Opera has one coupled to the UI for the
> "turbo" feature and it has been somewhat non-trivial to get acceptable
> quality.
>
> In general the problem with trying to measure something like bandwidth is
> that it is highly time-variable; it depends on a huge number of
> environmental factors like the other users/applications on the same
> connection, possible browser features like down-prioritising connections in
> background tabs, external environmental features like "the train just went
> into a tunnel" or "I just went out of range of WiFi and switched to 3G" and
> any number of other things. Some of those are temporary conditions, some are
> rapid changes to a new long-term state. Trying to present a single number
> representing this complexity in realtime just isn't going to work.

Yeah, that's what I had figured the process I described would be able
to work for - but I accept it must be more complicated than I have
accounted for. Thanks for the feedback :)

Re: [whatwg] Bandwidth media queries

[James Graham]

On Wed, 16 May 2012, Matthew Wilcox wrote:


First off I know that a number of people say this is not possible. I
am not wanting to argue this because I don't have the knowledge to
argue it - but I do want to understand why, and currently I do not.
Please also remember that I can only see this from an authors
perspective as I'm ignorant of the mechanics of how these things work
internally.

The idea is to have something like:






Without going deeper into the specific points, implementation experience 
suggests that even implementing a binary low-bandwidth/high bandwidth 
detection is extremely difficult; Opera has one coupled to the UI for the 
"turbo" feature and it has been somewhat non-trivial to get acceptable 
quality.


In general the problem with trying to measure something like bandwidth is 
that it is highly time-variable; it depends on a huge number of 
environmental factors like the other users/applications on the same 
connection, possible browser features like down-prioritising connections 
in background tabs, external environmental features like "the train just 
went into a tunnel" or "I just went out of range of WiFi and switched to 
3G" and any number of other things. Some of those are temporary 
conditions, some are rapid changes to a new long-term state. Trying to 
present a single number representing this complexity in realtime just 
isn't going to work.

Re: [whatwg] Bandwidth media queries

[Matthew Wilcox]

Ok, so really it's an efficiency of authoring problem; before I just
didn't get how it'd be any different to a viewport width from the
perspective of an author.

That said, when coupled with viewport responses... yeah, that could
get complicated to author. Essentially each bandwidth bracket would be
a multiplier for the number of cases you'd need to address.

Cheers again.



On 16 May 2012 20:00, Tab Atkins Jr.  wrote:
> It's not that bandwidth queries aren't possible, it's that they're not
> *useful* for the things you'd want to use them for, and they don't act
> like you'd want anyway.
>
> I explain much of the reasoning in 
> - while the blog post purports to be about resolution negotiation, it
> actually more generally covers why bandwidth queries are a bad idea.
>
> In short, bandwidth is often quite variable, particularly on the
> devices where you'd actually *want* to use this information.  This
> means the instantaneous bandwidth (what MQ would be using) can easily
> be useless to you.  It also means that you'll easily and commonly get
> into perverse situations where trying to be "bandwidth-friendly" ends
> up downloading *more* data than a naive page would.
>
> The author is just not in a good situation to be able to make sound
> decisions about how to react to bandwidth. You need a lot more
> information than a MQ can provide, and even if we provided it, the
> logic necessary to use that information *right* is fairly subtle and
> definitely not settled.
>
> This is why providing facilities for the author to just *tell* the
> browser about the relative filesizes of things, so it can make its own
> decisions about which resource to download.  This keeps the language
> simpler, because we don't have to communicate as much information.  It
> also centralizes the "what to do" logic into a small number of places
> (the browsers) where it has a better chance of being right, rather
> than hoping that thousands or milions of authors all stumble on the
> best solution together, and keep their pages updated as best-practices
> change.
>
> ~TJ

Re: [whatwg] Bandwidth media queries

[Tab Atkins Jr.]

It's not that bandwidth queries aren't possible, it's that they're not
*useful* for the things you'd want to use them for, and they don't act
like you'd want anyway.

I explain much of the reasoning in 
- while the blog post purports to be about resolution negotiation, it
actually more generally covers why bandwidth queries are a bad idea.

In short, bandwidth is often quite variable, particularly on the
devices where you'd actually *want* to use this information.  This
means the instantaneous bandwidth (what MQ would be using) can easily
be useless to you.  It also means that you'll easily and commonly get
into perverse situations where trying to be "bandwidth-friendly" ends
up downloading *more* data than a naive page would.

The author is just not in a good situation to be able to make sound
decisions about how to react to bandwidth. You need a lot more
information than a MQ can provide, and even if we provided it, the
logic necessary to use that information *right* is fairly subtle and
definitely not settled.

This is why providing facilities for the author to just *tell* the
browser about the relative filesizes of things, so it can make its own
decisions about which resource to download.  This keeps the language
simpler, because we don't have to communicate as much information.  It
also centralizes the "what to do" logic into a small number of places
(the browsers) where it has a better chance of being right, rather
than hoping that thousands or milions of authors all stumble on the
best solution together, and keep their pages updated as best-practices
change.

~TJ