[whatwg] Features for responsive Web design
jmather at itsmajax.com
Wed May 16 12:12:19 PDT 2012
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
On Wed, May 16, 2012 at 3:04 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
> On Wed, May 16, 2012 at 11:55 AM, Matthew Wilcox <mail at matthewwilcox.com> wrote:
>> On 16 May 2012 19:47, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
>>> On Wed, May 16, 2012 at 5:58 AM, Matthew Wilcox <mail at 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
>> 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.
More information about the whatwg