W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2012

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

From: Simon Pieters <simonp@opera.com>
Date: Mon, 14 May 2012 08:39:54 +0200
To: whatwg@whatwg.org, "Jason Grigsby" <jason@cloudfour.com>
Message-ID: <op.weacsuy9idj3kv@simons-macbook-pro.local>
On Sun, 13 May 2012 00:43:48 +0200, Jason Grigsby <jason@cloudfour.com>  
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]

I agree, but that is orthogonal (the proposals for both use cases could  
use either attribute syntax or element syntax).


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


-- 
Simon Pieters
Opera Software
Received on Monday, 14 May 2012 06:40:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:08 GMT