Re: Stretchy images shouldn't require media queries

On 6 Nov 2012, at 06:02, Eric Portis <lists@ericportis.com> wrote:

> 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.

That is something I have brought up previously, but after much consideration there wasn't a clear idea of how to address the problem without introducing great complexity (the only solution I could come up with has its own issues, and could well be a rabbit hole, but if you're interested: http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/ ). I believe DRY principles were deemed too problematic at the moment and focus was put onto getting a working <picture> instead, with the aim to address the DRY problem later. Which I think is the most practical way to go about it at the moment, but if you have any ideas I for one would love to hear them.

> 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.

I agree. As yet every approach is a compromise; they all sit at different places on the line.

> 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 personally would like that. The issues we have are caused mainly by pre-fetch behaviour. If we could turn that off via a parameter or a user preference then we'd have been able to "fix" responsive images over a year ago. It's my understanding that adjusting the way pre-fetch works is essentially a no-go.

> 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.

It's my believe that offering an optimally sized image would offset any speed loss from negating pre-loading - but that's pure opinion, it'd need to be tested, and I've never tried.

> 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?

The problem was discussed here: http://www.w3.org/community/respimg/2012/05/16/shouldnt-we-be-defining-content-not-context/ You might find the discussion useful, and it'd be great if you had any further insights into it :)

> —eric