[whatwg] Correcting some misconceptions about Responsive Images

[Anselm Hannemann]

Am 16.05.2012 um 09:13 schrieb 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.
Thanks for doing this effort it is really needed when I today saw some nasty conversations on twitter.
I don't like the way (mis)communication had gone but we should not fight verbal at all about such topics.
> 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.

I was one of them saying that. I do not know who read the whole story of our way to the picture element but
for me it still seems that there are none here in the mailing-list except Mat etc.
I will come back to it later…

> 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.
Here we go. It seems many have scan and skimmed the CGs topics but no one 
read carefully the discussions.
Of course we had the topics about bandwidth, browser's behavior on detecting and managing the MQ in the syntax.
Also resolutions and other things were actually discussed.

And that is my biggest concern:
If important people would have read the CGs discussions 
(which IMO they have the responsibility if they are in the role to set up a new spec) 
they would have known many more use-cases, problems than they actually do.
When we look at the topics going around here in mailing list, many many of them 
were already discussed in the CG. And I several times informed important people (I thought they were)
that they should talk to the browser vendors (they are working for them!) about our problems,
concerns and proposals. They never did or at least we never got a reply.

I think the WHATWG should respect the W3C with its community groups more. Or what are they for?
I mean we invested many hours of work into the topics and now we have to explain and discuss all again (sure with new valid arguments).
This is sad and should be done better (maybe by both sides) next time…

> 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.
Surely it does. But I think the biggest problem is that the micro-syntax is not 
developer-friendly (for the masses). At least this is my only problem with the solution.

> 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
-Anselm