On Sun, 13 May 2012, David Goss wrote:
A common sentiment here seems to be that the two proposed responsive image solutions solve two different use cases: - <img srcset> for serving different resolutions of a content image (for bandwidth and dpi) - <picture> for serving different versions of a content image (for art direction) ...and that neither solution can deal with both issues. I disagree. I would describe it as a single, broad use case: Serving different sources of an image based on properties of the client. These properties could include: - Viewport width/height - Containing element width/height - Device orientation - Colour capability - Old-fashioned media type (screen/print) - Connection speed - Pixel density - Things we haven't thought about/aren't an issue yet
Which of hese things are actual requirements that people need to meet and which are hypothetical? For example I think it is uncontroversial that viewport width/height is a real requirement. On the other hand, I have never heard of a site that switches assets based on display colour capability. Can you point to sites actually switching assets based on each property you listed?
Also note that there is a great difference in implementation complexity between various properties above. For example, viewport width/height is rather easy to work with because one can assume it won't change between prefetching and layout, so one can prefetch the right asset. On the other hand switching based on containing element width/height requires layout to happen before the right asset can be selected, so it has to be loaded late. This will significantly decrease the perceived responsiveness of the site.
Other properties like connection speed are very difficult to work with because they can have high temporal variability e.g. due to sharing of one connection by many consumers, due to temporary environmental conditions (train goes into a tunnel) or due to switching transports (wifi to 3G, for example). My suspicion is that trying to write a solution for switching based on connection speed would lead to people getting the "wrong" assets much of the time.
Note that these concerns argue, to a certian extent, *against* reusing a very general syntax that can express constraints that aren't relevant to the actual use cases, or that provide an attractive nuisance that encourages developers to do things that can't be implemented in a performant way.
