[whatwg] Correcting some misconceptions about Responsive Images

[Tab Atkins Jr.]

I've been doing a lot of work today correcting misconceptions about
the Responsive Images proposal that Hixie put into the spec today.  I
was pretty astonished at how much misinformation was flying around;
what's worse, this sort of misinformation was actually making people
*angry*, which doesn't exactly make people willing to calmly listen to
corrections.  So, hopefully this email finds everyone in calmer moods,
so we can get everyone on the same page.

1. "The Responsive Images CG was completely ignored." I keep hearing
this, and it's pretty annoying.  The responsive images thing is a
complete success story by any objective account: some people initially
brought up an idea, it was rejected, they went away for a bit and
developed the use-cases more fully, the idea was accepted and made it
into the spec.  That's *precisely* how the process should work -
everything came up roses here. The CG's work on elucidating use-cases
better was *invaluable* here.

The current solution in the spec isn't precisely the same as what the
CG proposed.  That's perfectly normal; the CG wasn't paying attention
to an important use-case (they either weren't paying attention to
resolution, or thought that device-pixel-ratio or a hypothetical
bandwidth media query would suffice, neither of which is true).  If
this sort of thing disillusions you, stay away from standards. ^_^
Having your ideas mutated into forms you didn't anticipate is
commonplace, as others point out cases you missed and suggest easier
or more elegant variants.  It's probably good to learn early if you're
not cool with this sort of thing - a *lot* of people don't have the
right kind of patience to suffer through standards work.

2. "@srcset doesn't solve all the use-cases."  Yes, it does.  There
are currently two major classes of use-cases.  The first is what the
CG mostly focused on, which is varying the image you deliver based on
breakpoints in your layout.  This is handled by the "NNNw" and "NNNh"
parts of the microsyntax - they specify that the image should only be
used if the viewport is at least a certain width or height.  This is
almost the same thing as the "min-width" and "min-height" Media
Queries, except it has better fallback behavior for when nothing
matches.

The second major class is serving the same image, but in different
resolutions based on the device's pixel density.  This is more complex
than it sounds (see http://www.xanthir.com/blog/b4Hv0 ), but @srcset
solves it pretty simply with the Nx part of the microsyntax, which
tells the browser the resolution of the image.  Browsers can handle
all the complications themselves.

3. "@srcset doesn't have good fallback behavior". Yup, it does. The
simplest way is to just do the simplest thing: provide both a @src and
a @srcset, and that's it.  This has good behavior in legacy UAs, and
in new ones.  The only downside of this is that if you're polyfilling
the feature in legacy UAs, you get two requests (first the @src, then
whatever the JS changes it to).

If this is problematic, there's a more verbose but still simple way to
handle this (afaik, first suggested by Odin):

<img src=data: srcset="foo.jpg 1x, foo2.jpg 2x"
style="display:none;"><noscript><img src="foo.jpg"></noscript>

In modern UAs, JS just has to remove the @style.  In legacy UAs, JS
removes the @style and sets the @src appropriately (the data: url
ensures that there's not an extra request before JS activates).  If JS
isn't turned on, the first image just never displays, but the second
one does.  This is more complicated and a bit more fragile than the
previous solution, but it only ever sends a single request.


Any others that people can think of?

~TJ