[whatwg] Features for responsive Web design

[Matthew Wilcox]

>>> 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
> images.

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
> wasn't.

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
> drawbacks.

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