Re: [whatwg] Features for responsive Web design

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).

> 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

> This seems like a good bit of complexity for now, though.  I'd prefer
> to iterate on the current proposal, keeping this kind of thing in
> mind.  In particular, adding something like url-templating would
> *massively* blow up the complexity of the feature, and delay its
> implementation.

I'm happy with that too, any progress is good progress and it doesn't
all have to come at once. That said I won't use any solution until it
has this level of abstraction: that's a criticism I brought up with
<picture> too (and why I wouldn't use that either in it's current RICG
form).

>
> ~TJ

Received on Wednesday, 16 May 2012 18:56:21 UTC