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

[Mathew Marquis]

On May 10, 2012, at 8:36 AM, Scott González wrote:

> You should look into the previous discussions at
> http://www.w3.org/community/respimg/
> 
> There's also a prototype using media queries at
> https://github.com/scottjehl/picturefill. I realize you specifically said
> you think media queries don't solve all of the problems, but it seems worth
> looking at.
> 

I can’t second Scott’s suggestion enough. There is a ton of history and valuable conversation around this topic already in the Community Group, and we’ve been working with a couple of browser reps trying to get this thing solved. We’ve even gone so far as to put the solution that seems to have the most legs together as a sort-of spec, so all the details are in one easily-parsed place: https://github.com/Wilto/respimg


> 
> On Thu, May 10, 2012 at 3:58 AM, Edward O'Connor <eoconnor at apple.com> wrote:
> 
>> 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
>> 
>>