[whatwg] <img srcset> for responsive bitmapped content images

[Edward O'Connor]

Hi,

When authors adapt their sites for high-resolution displays such as the
iPhone's Retina display, they often need to be able to use different
assets representing the same image. Doing this for content images in
HTML is currently much more of a pain than it is in CSS (and it can be a
pain in CSS). I think we can best address this problem for bitmap[1]
content image by the addition of a srcset="" attribute to the existing
<img> element.

The srcset="" attribute takes as its argument a simplified variant of
the image-set() microsyntax[2]. It would look something like this:

<img src="foo-lores.jpg"
     srcset="foo-hires.jpg 2x, foo-superduperhires.jpg 6.5x"
     alt="decent alt text for foo.">

<img srcset> takes one or more comma separated image specifiers. An
image specifier consists of a URL to an image asset and an associated
scale factor, expressed as a number followed by the literal character
'x'. (The value of <img src> is treated as if it had a 1x scale
specified, so you can avoid duplicate references to the base asset.)

User Agents may make their asset selection before fetching any of the
assets, thus avoiding multiple asset loads & the associated performance
problems in constrained bandwidth environments.

The intrinsic size of the <img> can be computed by dividing the
intrinsic size of the actual image asset chosen with that asset's
associated scale factor. Suppose that foo-lowres.jpg is 100x100 and
foo-highres.jpg is 200x200 in the above example. If the UA chooses
foo-lowres.jpg, it computes the intrisnic size as (100/1)x(100/1) =
100x100. If the UA chooses foo-highres.jpg, it computes the intrisnic
size as (200/2)x(200/2) = 100x100.

A nice thing about this proposal is its backwards compatibility story.
Browsers which don't yet support <img srcset> will simply use the asset
referenced by <img src>. A polyfill could easily be written to check for
<img srcset> & swap out a different asset into <img src>, much like
existing libraries which check for data-fullsrc="" or the like.

Why provide a scale factor and not a media query? Well, media queries
are claims about UA state, whereas here we're asserting something about
the relationship between the image assets. Also, User Agents should be
free to use whichever asset they deem best suited to their current
situation, taking into account not just "media-queriable things" like
device resolution but also any scaling applied to the <img> with CSS,
its width="" and height="" attributes, or even things like the current
page zoom level.

Of course there are other things like bandwidth availability, data plan
usage, etc. that web developers might want to take into account when
choosing which image assets to load. This is definitely something worth
exploring. In the future we could extend the asset descriptors to cover
such cases. Something like this, maybe:

 <img srcset="foo-lowres.jpg 1x low-bandwidth,
              foo-highres.jpg 2x high-bandwidth">

I'm purposefully not making a proposal for how to describe bandwidth,
data plan usage, or such things here. 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.

One downside to this proposal is that the srcset="" attribute takes a
microsyntax, and as a rule we try to avoid novel microsyntaxes in
attribute values. I think this particular microsyntax is pretty
straightforward and shouldn't cause all that much confusion for authors.

I think this is preferable to adding a suite of attributes with complex
inter-relationships, such as in Anselm Hannemann's proposal from last
August[3]. In such a proposal, we would either need to have a pre-
approved list of image scales (like Anselm's xs, s, m, l, xl), which
over-constrains designers' ability to create, or we would be introducing
user data into attribute names which—with the one exception of the
data-*="" attributes—is something I really don't think we should do.

Some have argued that we should "just use conneg" to serve the best
image. This isn't an acceptable solution for at least three reasons:

* The server doesn't have all of the relevant information needed to
  pick the best image, and sending that information with every image
  asset request is bandwidth-intensive and enables increased user
  fingerprinting.

* HTML is used in a lot of contexts, such as in EPUB, in which there's
  no server to negotiate with in the first place.[4]

* The UA should be able to "swap out" one asset for another
  transparently after the page has loaded. For instance, the UA might
  want to swap things out when the user zooms in.

I also think this approach is better than minting a new image element,
but I'll make that argument in another email.


Ted

1. "What responsive image problem? Just use SVG!" :)

2. I've proposed image-set() for CSS4 Images. Here's the relevant post
   to www-style:
     http://lists.w3.org/Archives/Public/www-style/2012Feb/1103.html
   An implementation of image-set() has recently landed in WebKit.

3. http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-August/032977.html

4. http://lists.w3.org/Archives/Public/public-html/2011May/0401.html