- From: Mathew Marquis <mat@matmarquis.com>
- Date: Mon, 21 May 2012 20:36:22 -0400
- To: Kornel Lesiński <kornel@geekhood.net>
- Cc: whatwg@lists.whatwg.org
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.pt@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
Received on Tuesday, 22 May 2012 00:37:14 UTC