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