W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2012

Re: [whatwg] Bandwidth media queries

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 16 May 2012 12:00:52 -0700
Message-ID: <CAAWBYDAvt2Yvs+etmZdSD_WNin=nz8=onUEKQaB1iv7JDhRSwQ@mail.gmail.com>
To: Matthew Wilcox <mail@matthewwilcox.com>
Cc: WHATWG List <whatwg@whatwg.org>
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

Received on Wednesday, 16 May 2012 19:01:49 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:42 UTC