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

Re: [whatwg] Features for responsive Web design

From: Jacob Mather <jmather@itsmajax.com>
Date: Wed, 16 May 2012 15:12:19 -0400
Message-ID: <CAF_LGSteE9cC8mXYVwKq2X5v827k+fH2yfvgRddwQ+x_27voug@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: whatwg <whatwg@lists.whatwg.org>, Henri Sivonen <hsivonen@iki.fi>, Matthew Wilcox <mail@matthewwilcox.com>, PJ McCormick <pj@mynameispj.com>
Maybe this is the better question:

Why does the pre-loader matter so much?

Basing the selected image off of browser width is inherently
backwards. The content should be informed by the layout, not by the
browser.

On Wed, May 16, 2012 at 3:04 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Wed, May 16, 2012 at 11:55 AM, Matthew Wilcox <mail@matthewwilcox.com> wrote:
>> On 16 May 2012 19:47, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>> On Wed, May 16, 2012 at 5:58 AM, Matthew Wilcox <mail@matthewwilcox.com> wrote:
>>>> Also, srcset does not abstract the control points away from the image
>>>> itself. I have already been over why this is a problem and
>>>> future-unfriendly. Breakpoints are based on a when a *design* becomes
>>>> visually broken, not on the width of a device. So, when a design
>>>> changes, so will the response breakpoints, and that would mean having
>>>> to revisit and edit every image that's had srcset applied - unless I
>>>> am missing something (which given the last day or two, I may well be).
>>>
>>> You're right that changing your breakpoints requires changing all the
>>> @srcset declarations.  An unfortunate aspect of our inability to
>>> abstract away some of the functionality without breaking some of the
>>> features (like being preloader-friendly).
>>
>> I must admit, I am still confused about the pre-loader issue. I'm not
>> sure whether the plan is that we'd be able to convince vendors to
>> disable it on <img/> elements containing srcset (or whatever solution
>> ends up final) or whether this is something that has to be worked with
>> now (in which case the <meta> variable idea seems to me the only one
>> that could work).
>
> Given the current syntax, the idea is that browsers will be able to
> preload the *correct* image from @srcset.  They have all the
> information necessary to make the decision at parse-time.
>
> I'm not entirely sure how accurate this is, though.  Some better info
> one way or another would be useful.
>
>
>>> However, something similar to your idea certainly seems possible to
>>> use in an extention of the syntax.  Rather than specifying a w/h
>>> component, give a 'case' component that refers to a breakpoint defined
>>> elsewhere.  This could even potentially extend into url-templating.
>>
>> That's the conclusion that was come to at the RICG too, and why
>> http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/
>> was put forward. I haven't received promising feedback from the WHATWG
>> about it though :s
>
> Yeah, I was purposely calling back to the post you linked above.
>
> I gave it some criticism here in WHATWG.
>
> ~TJ
Received on Wednesday, 16 May 2012 19:12:51 GMT

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