Note that this is also my major criticism of <picture> and the reason why I would not use it in the current CG state - and why I've been looking into <meta> variables as a method of abstracting the response points away from the responding element.
I think this is a very important consideration. Anything baking response points directly into an element will be hell to work with in any re-design. -Matt On 16 May 2012 13:58, Matthew Wilcox <m...@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). > > -Matt > > On 16 May 2012 13:55, Matthew Wilcox <m...@matthewwilcox.com> wrote: >> Chalk me up as another making that mistake. Properties on elements >> usually describe a property of the element. Not a property of >> something else (like the viewport). >> >> I'm happier than I was about srcset - but why does the spec assume >> pixels? Or does it? >> >> Use case: design breakpoints can and often are based on non-pixel >> units. em's, for example. As far as I can tell, srcset does not work >> with units other than pixels, so how could it work reliably with >> designs done in non-pixel units? >> >> -Matt >> >> On 16 May 2012 13:38, PJ McCormick <p...@mynameispj.com> wrote: >>>> >>>> On Wed, May 16, 2012 at 5:25 AM, Henri Sivonen <hsivo...@iki.fi> wrote: >>>> >>>> On Wed, May 16, 2012 at 2:46 PM, Jeremy Keith <jer...@adactio.com> wrote: >>>>> > You're right. I was thinking that the values (Nh Nw Nx) described the >>>>> *image* but in fact they describe (in the case of Nh and Nw) the viewport >>>>> and (in the case of Nx) the pixel density of the screen/device. >>>>> > >>>>> > I suspect I won't be the only one to make that mistake. >>>>> >>>>> Indeed. I made the same mistake initially. The what's currently in the >>>>> spec is terribly counter-intuitive in this regard. >>>> >>>> >>> I also made the same mistake, and it took combing through all of >>> yesterday's and this morning's discussions on the topic for me to finally >>> understand it properly. And I consider myself to be a fairly competent >>> developer, not someone just starting out with HTML. >>> >>> Now that I do understand I'm honestly happier with @srcset as a concept, >>> but my problems with the syntax itself still remain. In fact, they might be >>> amplified. Surely we can refine this into a better, more easily understood >>> syntax. >>> >>> >>> >>> >>> On Wed, May 16, 2012 at 5:25 AM, Henri Sivonen <hsivo...@iki.fi> wrote: >>> >>>> On Wed, May 16, 2012 at 2:46 PM, Jeremy Keith <jer...@adactio.com> wrote: >>>> > You're right. I was thinking that the values (Nh Nw Nx) described the >>>> *image* but in fact they describe (in the case of Nh and Nw) the viewport >>>> and (in the case of Nx) the pixel density of the screen/device. >>>> > >>>> > I suspect I won't be the only one to make that mistake. >>>> >>>> Indeed. I made the same mistake initially. The what's currently in the >>>> spec is terribly counter-intuitive in this regard. >>>> >>>> > I can see now how it does handle the art-direction case as well. I think >>>> it's a shame that it's a different syntax to media queries but on the plus >>>> side, if it maps directly to imgset in CSS, that's good. >>>> >>>> It seems to me that Media Queries are appropriate for the >>>> art-direction case and factors of the pixel dimensions of the image >>>> referred to by src="" are appropriate for the pixel density case. >>>> >>>> I'm not convinced that it's a good idea to solve these two axes in the >>>> same syntax or solution. It seems to me that srcset="" is bad for the >>>> art-direction case and <picture> is bad for the pixel density case. >>>> >>>> (I think the concept of dpi isn't appropriate for either case, FWIW. I >>>> think "the number of horizontal and vertical bitmap samples doubled >>>> relative to the traditional src image" works much better conceptually >>>> for Web authoring than making people do dpi math with an abstract >>>> baseline of 96 dpi. Anecdotal observation of trying to get family >>>> members to do dpi math for print publications suggests that it's hard >>>> to get educated people do dpi math right even when an "inch" is a real >>>> inch an not an abstraction.) >>>> >>>> -- >>>> Henri Sivonen >>>> hsivo...@iki.fi >>>> http://hsivonen.iki.fi/ >>>>