[whatwg] Features for responsive Web design
mail at matthewwilcox.com
Fri May 18 15:11:45 PDT 2012
>>> Make no mistake; this is not a pride or attachment thing, this is a
>>> knowing the reasons thing. I personally don't think <picture> answers
>>> things well enough, nor do I think srcset does. Not for general use
>>> cases - but for specific one-off use cases, each has benefits.
>> Absolutely. And from what I read (and I admit not reading the entire
>> archive of messages, but still, prefer to say my piece anyway) the
>> main concern about picture was the potencial verbosity. Instead of
>> trying to solve this issue, it got discarded.
> <picture> in its current form is unable to support bandwidth-based
> negotiation well
By all accounts no solution proposed can do this. This is not a
<picture> only problem.
> (and that's not simply a matter of adding bandwidth media
> query) and has no mechanism to specify scaling factor for intrinsic sizes of
Not actually sure what "intrinsic sizes of images" means.
> IMHO those are pretty serious drawbacks that limit its functionality, which
> is much worse than "ugly, but gets job done" state of srcset.
I see no difference between the end result of either syntax. Both
approaches fail utterly in abstracting the query from the mark-up,
which means both approaches are suited only to individual images.
Should the design of the site change at any point, both solutions
break completely. It's a major problem I pointed out with <picture>
over in the CG. Srcset is no better in this regard.
> There are two categories of use-cases ("art-directed" and
> "dpi/optimization") and <picture> is suited for only one of them, so please
> don't frame the decision as "discarding" of a perfectly good solution, as it
Picture dealt with both of these by simple use of the pixel density
media query - i.e, in exactly the same way CSS already does it. I do
not understand your argument.
> srcset addresses both dpi/optimisation and art-directed use-cases. It has
> its own problems, such as confusing microsyntax, so suggestions how to
> improve this are welcome.
Agreed, and already underway.
> Lamenting <picture> and accusing WHATWG of wrongdoing is not productive.
With respect, finding out where there have been fuck-ups is in
everyone's interest if we want to get the most out of the process and
communities who are all trying to better the web.
> If you'd like to see <picture> proposal succeed, then please help fixing its
I've said I don't. No part of my argument said I condone continued
argument for supporting picture - I in fact said I don't like it and
haven't liked it since it was in the CG.
> Make selection and embedding of 2x images easier.
> Give UA freedom
> to use cached higher-quality images when it can. Give UA freedom to choose
> images to minimize bandwidth or maximize quality. Reduce verbosity of most
> common cases.
> I've tried to raise those issues on the Responsive Images group's
> mailinglist, but got no constructive feedback.
That last bit is annoying. Some of the key players in that group seem
to ignore stuff since they decided <picture> was finished - I've had
the same problem myself.
> regards, Kornel Lesiński
More information about the whatwg