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

Re: [whatwg] Features for responsive Web design

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Sat, 19 May 2012 11:31:40 -0700
Message-ID: <CAAWBYDBT_7kGHndmv0UCTnVF7HMB-LYyrXGXR377Lo_r5JYb=g@mail.gmail.com>
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 GMT

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