[whatwg] Implementation complexity with elements vs an attribute (responsive images)
jason at cloudfour.com
Sat May 12 15:43:48 PDT 2012
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.
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. 
* Example 2: On the Nokia Browser site where it describes the Meego browser, the Nokia Lumia is show horizontally on wide screens. As the screen narrows, the Nokia Lumia is then shown vertically and cropped. 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
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.
* 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>
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:
> 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:
<source src="mobile.jpg" />
<source src="medium.jpg" media="min-width: 600px" />
<source src="fullsize.jpg" media="min-width: 900px" />
srcset="foo-hires.jpg 2x, foo-superduperhires.jpg 6.5x"
alt="decent alt text for foo.">
Which would make no one happy.
 Yes, yes, this is an exaggeration, but you get my point.
More information about the whatwg