- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Sat, 19 May 2012 11:31:40 -0700
- To: Matthew Wilcox <mail@matthewwilcox.com>
- Cc: whatwg@lists.whatwg.org
On Sat, May 19, 2012 at 2:46 AM, Matthew Wilcox <mail@matthewwilcox.com> wrote: > On 19 May 2012 00:37, Kornel Lesiński <kornel@geekhood.net> wrote: >> On Fri, 18 May 2012 23:11:45 +0100, Matthew Wilcox <mail@matthewwilcox.com> >> wrote: >>>> <picture> in its current form is unable to support bandwidth-based >>>> negotiation well >>> >>> By all accounts no solution proposed can do this. This is not a >>> <picture> only problem. >> >> srcset allows UA to pick any image density regardless of actual screen >> density, so e.g. Safari on iPhone 4 on GPRS/EDGE connection could download >> 1x images, instead of 2x. > > Yes indeed, but the problem is not about srcset, <picture> or anything > else: it's that, as has been pointed out repeatedly to those of us > asking about bandwidth media queries, the browser simply can't do > reliable bandwidth detection. That effects srcset as much as anything > else. So while technically srcset allows for this, the browser itself > does't, so it can never be used in the manner you're describing. I'm not sure where you got that idea; no one has said that bandwidth detection is impossible. We've merely said that it's *hard*, and it involves much more than a simple "what's the instantaneous bandwidth right now?". Opera Turbo, for example, has high/low bandwidth detection for deciding what behavior to use. It was very difficult to get it right, but I presume they've settled on a decent solution now. *Because* it's hard, we shouldn't put the problem in the hands of devs. It's better to solve it a handful of times in browsers, than to expect ten thousand individual developers to all solve the problem correctly. >> UAs are also free to download 1x image first, and then 2x image after >> onload, etc. Declarative nature of descriptors, as opposed to imperative >> MQs, allows UAs to innovate in this area and come up with new uses that >> authors didn't predict/express in MQ. > > This would be no better than current JS approaches, in fact making it > worse by adding to the page load size rather than optimising it. No, it's definitely better, because, as already stated, the browser can make these sorts of decisions intelligently. Grabbing the cheapest assets for a fast load then swapping them out when a slow load is less noticeable is a smart decision if the bandwidth supports it. >> The syntax allows addition of "KB" descriptor later, which — assuming UAs >> will figure out how to measure actual bandwidth well enough — will allow >> even more sophisticated selection based on file size (rather than only 1x/2x >> scale factors which are only a proxy for the file size). > > As above; this seems set not to happen. Besides, how is it going to > know the file size unless you explicitly state it in the srcset > somewhere? I'm not sure I understand the question. He's talking about a descriptor that lets you explicitly state the file size. ~TJ
Received on Saturday, 19 May 2012 18:32:31 UTC