- From: Matthew Wilcox <mail@matthewwilcox.com>
- Date: Wed, 16 May 2012 20:09:12 +0100
- 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 UTC