Re: Stretchy images shouldn't require media queries

On Sun, Nov 4, 2012 at 3:07 PM, Matthew Wilcox <elvendil@gmail.com (mailto:elvendil@gmail.com)> wrote:
> It's not future proof and it pollutes mark-up with design data.


We certainly agree on this. The general consensus seems to be that having to wait until all of the CSS is in before choosing which asset to download is a deal-breaker. But I haven't heard much concern for how <picture> and srcset="" both muddy content & presentation to work around the prefetching problem. For myself (and from the sounds of it, for you) that "pollution" is worth paying a high price to avoid.

Presentational concerns have always been baked into images, in a way... images have fixed, native dimensions. Bandwidth-conscious authors have always tailored image sizes to fit particular layouts. This is a bit like having to put explicit line breaks in your text blocks which you'd then have to adjust whenever bringing that text into a new context… I would hope that a responsive images solution would allow content images to be handled in a more, not less, presentationally agnostic way.

The Adaptive Images solution is interesting. I particularly how it solves the problem of picking which sizes to render your set of images at (described well here: http://blog.cloudfour.com/how-do-you-pick-responsive-images-breakpoints/) by, in effect, letting the devices that are doing the requesting decide. This gives you some of the freedom-from-guesswork & flexibility of a completely dynamic solution like IIPImage (http://iipimage.sourceforge.net/2012/08/responsive-images-using-iipimage/) but without making the server resize an image for *every* GET request.

But as you point out, AI errs on the side of downloading too much, especially at the larger end of the screen-size spectrum. Putting explicit layout-based information (in the form of max-size caps) in PHP seems better than putting them in the markup, but it's not ideal. AI would be particularly ill-suited at handling the example layout I put together for my original email (http://ericportis.com/etc/stretchy-images-example/) — on that layout, larger viewports move the image over to a sidebar, making it *smaller*... I don't think my example is too far-fetched.

Different compromises are going to make sense in different contexts. I'm saying that authors should be able to CHOOSE the "keep layout considerations out of my html and defer image loading until all of the CSS is in" compromise via markup, rather than via hacky javascripts (as I've currently been resorting to). I'm also expressing a vague hope—as someone unqualified to make statements about the present or future inner workings of browsers—that the performance hit this would currently impose could be mitigated or worked around in the future, somehow.

I was heartened to hear Opera dev Odin Hørthe Omdal speak from what sounded like a similar set of concerns & hopes in the RICG TPAC video that was recently posted.

But...

> In order to pick a size to use the browser would have to know how big the space was the image is going to fit into. But the way websites work is the space is dictated by the content. It's a circular problem. So you can't just pick the right sized asset to load based on the "available space" because you don't know the available space.
  
You seem to suggest that it's not simply a problem of waiting until the CSS is in, but something more fundamental? My hacky little script seems to be working (it decides which resource to load based on the parent element's width & the viewport's height, calced after jQuery's 'ready' event)… I'm trying to conjure scenarios in which a paradoxical-circular-definition comes into play, but can't quite wrap my brain around it. Any examples?


—eric

Received on Tuesday, 6 November 2012 06:02:51 UTC