Balls, that should have read: "...they go and load the matching resource; which is a 1200px wide image"
i.e., the same as the content column at a viewport width of 1600px. On 28 May 2012 20:46, Matthew Wilcox <m...@matthewwilcox.com> wrote: > On 28 May 2012 20:37, Matthew Wilcox <m...@matthewwilcox.com> wrote: >> On 28 May 2012 18:21, Scott Jehl <sc...@scottjehl.com> wrote: >>> Matt Wilcox's first two points are fair, though I see them as >>> inconveniences rather than blockers. >>> >>> To his third point, however: >>> >>> I see the suggestion mentioned on occasion that content image sizes and >>> design breakpoints should be coordinated, but in practice, I personally >>> haven't found much of a need for that coordination. >>> >>> In the responsive layouts I've worked on, content image sizes and their >>> breakpoints were chosen for completely different reasons than the design >>> (CSS) breakpoints: the former for sensible jumps in file size to match >>> screen dimension and/or density, and the latter for how content modules are >>> visibly designed at given viewport dimensions. >>> >>> Design breakpoints can be plentiful, especially when factoring in all the >>> minor and major tweaks in multi-column responsive layout. Yet for content >>> images, I've found the need for fewer breakpoints, or even entirely >>> different breakpoints than the design. In a site like the bostonglobe.com >>> for example, 2-3 image sizes provide sensible jumps in file size, and >>> because the images live a fluid layout, they scale to fill the layout gaps >>> as the CSS breakpoints shift much more frequently around them. If an image >>> needs finer coordination than that with its design, perhaps it might be >>> considered a design asset that should be handled in CSS with background >>> images; I guess I'd need to see some examples of where this problem could >>> occur. >>> >>> There are sure to be gray areas here. I'm just not sure I agree that the >>> redesign problem is all that much of a real concern for this feature. Matt, >>> if you disagree, do you have any examples you could provide? >> >> Sure :) In many ways I agree with you - the entire <img> problem is >> really all about *the space they fit into* and not about the design. >> And if CSS and HTML could work with that then we would be in a far >> better position because they'd be able to adapt to any space >> regardless of what the design is. The problem is that CSS media >> queries do not work with the space an image fits into - they can only >> measure the viewport. Which means that in practice you're actually >> coupled to the design breakpoint, even when you're intentionally >> working with the containing element into which the image is sitting. >> >> I.e., the space into which the image can fit is defined in the design >> breakpoint. It can't be known any other way because we can't measure >> the containing space itself - we have to define it as part of the >> design based on the value of the viewport width. >> >> Does that make sense? > > To illustrate the example: > > I have my first design, and it is intended for 1600px wide viewports. > In this design I have a main column that's 1200px wide, and I've set > all my <img>'s to adapt to that breakpoint. When those <img>s see a > viewport in excess of 1600px they go and load the matching resource; > which is a 1600px wide image. All is dandy. > > Two years later there's a re-design, and I've got hundreds of blog > posts with embedded <img> elements that match a 1600px wide viewport. > But the re-design isn't the same layout. It now has three columns at > that viewport width, not one main column. And now all of the <img> > elements match the viewport... but lead to images which are much too > large for the new design. > > Or, even worse, the new design has completely different breakpoints, > and the <img>'s that are being loaded when the viewport hits 1600px > are completely at odds with the layout bracket that I'd defined for > 1200-1800px ranges. > > This is what I mean by saying that we're tying our <img> elements to > design breakpoints. Everything is based on Viewports, and we could > *really* do with them not being. That's incredibly unlikely to happen > though because the technologies just aren't designed that way. Which > means we have to hope for a second-best approach of some hefty > abstraction.
