[whatwg] Implementation complexity with elements vs an attribute (responsive images)
James Graham
jgraham at opera.com
Sun May 13 02:14:56 PDT 2012
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.
More information about the whatwg
mailing list