[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. <jackalmage at gmail.com> 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 <http://www.xanthir.com/blog/b4Hv0>
> > - 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