[whatwg] Implementation complexity with elements vs an attribute (responsive images)

[Mathew Marquis]

I’ve put together a summary of potential use cases addressed by the picture markup and posted them to the WHATWG wiki, along with a few key implementation details: http://wiki.whatwg.org/wiki/Adaptive_images

I don’t mind saying that the `img set` markup is inscrutable to the point where I may well be missing the mark on what it’s trying to achieve, but it certainly seems to overlap with many of the things for which media queries were intended—albeit in a completely siloed way. As media queries continue to advance over time, are there plans to continue adding functionality to `img set` in parallel? I would hate to think we could be painting ourselves into a corner for the sake of easier implementation on the UA side.

I don’t claim to be any smarter than the average developer, but I am speaking as a core contributor to jQuery Mobile and having worked on the responsive BostonGlobe.com designs: tailoring things for client capabilities is kind of my thing. I fear the developer community has little hope of understanding this pattern, and there has been no small amount of consensus on that point: http://www.w3.org/community/respimg/2012/05/11/respimg-proposal/#comments

I worry that, when faced with this markup, developers will simply opt to serve the largest possible image in a src. In fairness, that approach "works" with far less headache.

-Mat Marquis


On May 12, 2012, at 6:43 PM, Jason Grigsby wrote:

> On May 11, 2012, at 8:52 PM, Simon Pieters wrote:
> 
>> There seem to be two proposals for what syntax to use for the responsive images use case: several elements vs. an attribute.
> 
> There are two proposals because they solve two different use cases. Both use cases are becoming increasingly important. Unfortunately, these use cases are commonly collapsed into one. I have done it myself in the past. I tried to clarify the use cases recently.[1]
> 
> Use case #1
> -----------
> Document author needs to display different versions of an image at different breakpoints based on what I’m calling, for a lack of a better phrase, art direction merits.
> 
> * Example 1: News site shows photograph speaking at a auto factory. On wide screens, the news site includes a widescreen version of the photograph in which the cars being built can clearly be seen. On small screens, if the photograph is simply resized to fit the screen, Obama’s face is too small to be seen. Instead, the document author may choose to crop the photograph so that it focuses in on Obama before resizing to fit the smaller screen. [1]
> 
> * Example 2: On the Nokia Browser site where it describes the Meego browser[2], the Nokia Lumia is show horizontally on wide screens[3]. As the screen narrows, the Nokia Lumia is then shown vertically and cropped[4]. Bryan and Stephanie Rieger, the designers of the site, have talked about how on a wide screen, showing the full phone horizontally showed the browser best, but on small screens, changing the img to vertical made more sense because it allowed the reader to still make out the features of the browser in the image.
> 
> Current proposed solution: <picture> element[5]
> 
> Use case #2
> -----------
> For a variety of reasons, images of various pixel density are needed. These reasons include current network connection speed, display pixel density, user data plan, and user preferences.
> 
> * Example 1: The use of high-density images for the new iPad on Apple.com.[6]
> 
> * Example 2: A user on a slow network or with limited data left may explicitly declare that he or she would like to download a high resolution because they need to see a sharper version of an image before buying product, etc.
> 
> Current proposed solution for use case #2: <img srcset>[7]
> 
> IMHO
> ----
> Neither proposed solution handles all of the use cases. I’m not convinced that one solution needs to solve both of them, but I do think if we’re getting close to implementing one of the proposed solutions, we need to consider how it would work in conjunction with a solution for the other use case.
> 
> To be more specific, if <img srcset> were to be implemented in a browser--potentially solving use case #2, but leaving use case #1 open--what would happen when we realized that use case #1 still needed to be solved? Would we end up with some bastardized mixture of <picture> and <imgset> syntax?
> 
> When Ted proposed <img srcset>, he wrote[7]:
> 
>> Ultimately I don't think addressing the multiple-resolution case needs to wait for a solution to these other cases. We don't need to "SOLVE ALL THE PROBLEMS!" right now.
> 
> 
> In a similar vein, the responsive images community group, focused on use case #1 and explicitly chose to ignore the problems described in use case #2.
> 
> While I agreed with that focus earlier, I now think this may be a mistake. As much as I don’t want to bog down solving either use case, it seems likely that if we don’t look at both at the same time, that we’ll end up with[8]:
> 
> <picture alt="">
>    <source src="mobile.jpg" /> 
>    <source src="medium.jpg" media="min-width: 600px" /> 
>    <source src="fullsize.jpg" media="min-width: 900px" /> 
>    <img src="foo-lores.jpg"
>     srcset="foo-hires.jpg 2x, foo-superduperhires.jpg 6.5x"
>     alt="decent alt text for foo.">
> </picture>
> 
> Which would make no one happy.
> 
> -Jason
> 
> ----
> [1] http://blog.cloudfour.com/a-framework-for-discussing-responsive-images-solutions/
> [2] http://browser.nokia.com/smartphones.html
> [3] http://browser.nokia.com/resources/images/home-feature.png
> [4] http://browser.nokia.com/resources/images/smartphones/choose-meego@320.png
> [5] https://github.com/Wilto/respimg
> [6] http://blog.cloudfour.com/how-apple-com-will-serve-retina-images-to-new-ipads/
> [7] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-May/035746.html
> [8] Yes, yes, this is an exaggeration, but you get my point.
>