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

Re: [whatwg] Bandwidth media queries

From: Matthew Wilcox <mail@matthewwilcox.com>
Date: Wed, 16 May 2012 20:09:12 +0100
Message-ID: <CAMCRKiLsW70up2x_dc0YPcXizhBmj_=wk-kpm-1yzrNK+bJPrw@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: WHATWG List <whatwg@whatwg.org>
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@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
Received on Wednesday, 16 May 2012 19:11:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:08 GMT