Re: [whatwg] Media queries, viewport dimensions, srcset and picture

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 <mail@matthewwilcox.com> wrote:
> On 28 May 2012 20:37, Matthew Wilcox <mail@matthewwilcox.com> wrote:
>> On 28 May 2012 18:21, Scott Jehl <scott@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.

Received on Monday, 28 May 2012 19:48:47 UTC