- From: Matthew Wilcox <mail@matthewwilcox.com>
- Date: Wed, 16 May 2012 20:14:04 +0100
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: whatwg <whatwg@lists.whatwg.org>, Henri Sivonen <hsivonen@iki.fi>, PJ McCormick <pj@mynameispj.com>
On 16 May 2012 20:04, 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. Cool. That makes sense but would require the browser to update it's pre-parser behaviour I imagine (i.e., scan the whole element rather than just try as soon as the src has been read - so it's not backward compatible right now) :) >>> 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. > Ah, I thought you were. I'll go have another look because I think I missed it - I'm only aware of one person feeding back - but then it's the end of the day and I'm not wholey convinced I won't see your reply and then remember reading it. It's been a busy day. Cheers Tab. > ~TJ
Received on Wednesday, 16 May 2012 19:14:36 UTC