On 28 May 2012 20:37, Matthew Wilcox <[email protected]> wrote: > On 28 May 2012 18:21, Scott Jehl <[email protected]> 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.
