On Fri, 18 May 2012 20:24:00 +0100, André Luís <andreluis...@gmail.com>
wrote:
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 (and that's not simply a matter of adding bandwidth media
query) and has no mechanism to specify scaling factor for intrinsic sizes
of images.
IMHO those are pretty serious drawbacks that limit its functionality,
which is much worse than "ugly, but gets job done" state of srcset.
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 wasn't.
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.
Lamenting <picture> and accusing WHATWG of wrongdoing is not productive.
If you'd like to see <picture> proposal succeed, then please help fixing
its drawbacks. 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.
--
regards, Kornel Lesiński
