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

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.

Received on Sunday, 13 May 2012 09:15:30 UTC