On May 18, 2012, at 5:19 PM, Kornel Lesiński wrote:
> 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.
Is there currently any documentation explaining how bandwidth is better handled
by `srcset`? Seeing as any discussion around bandwidth is almost entirely
theoretical, I have a hard time understanding where bandwidth concerns preclude
one approach or the other.
There’s a case to be made that few people implementing any form of “responsive
images” solution will find a need to rely on an image’s intrinsic width, as
doing so effectively negates any flexibility to begin with, which is almost
entirely the point of either solution. This is a valid point, however, and very
likely something that we could solve on the implementor’s side.
There’s no prior precedent this sort of thing—there’s no reason we can’t find a
way to preserve an image’s intrinsic width using `picture`. I wonder if simply
adding `width` and `height` attributes on the element (similar to `img`) might
solve this, in the event that the author wants to rely on an intrinsic size
instead of CSS?
>
> 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.
André didn’t seem to claim any loyalty to one solution or the other and, unless
I’ve missed something earlier in the thread, certainly didn’t accuse anyone of
“wrongdoing.” You’ve jumped to an oddly defensive place here, and that only
reinforces an “us vs. them” perception that I’m certain we’d all prefer to move
away from. I know I would.
> 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.
This is where I assumed we would be working with you, and I continue to hope
that we can. I’d really prefer there not be “sides” in this, rather than all of
us seeking the best possible solution. If you feel `picture` could have
potential given improvements on the UA end, well, that’s what we’re here
for—your input, and your collective expertise.
If we can bring `picture` in line with what implementors have in mind while
preserving something close to the markup pattern authors prefer, we’ll have a
solution that benefits everyone equally.
> I've tried to raise those issues on the Responsive Images group's
> mailinglist, but got no constructive feedback.
We were admonished in an earlier thread for using the RICG’s mailing list to
work in a vacuum (though it was seldom used, and any meaningful conclusions
were published to the RICG). If this is the correct forum for these ongoing
discussions, it’s likely best that we keep it here.
>
> --
> regards, Kornel Lesiński
