On Mon, 21 May 2012 19:36:22 -0500, Mathew Marquis <m...@matmarquis.com>
wrote:
<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.
No, and bandwidth proposal for srcset isn't fleshed out yet.
My — theoretical — take on this is that it's easier and safer to declare
image sizes (e.g. in KB) and let UA figure out which ones it wants, than
to add a bandwidth media query.
Reasons are:
- MQ model of matching current state is not suited for variable thing
like bandwidth.
- MQ would require somehow explicitly quantifying bandwidth, e.g. in
mbps, and exposing that accurately seems to me harder than having less
exposed/less sophisticated logic in UAs like picking smallest images when
UA is on 2G mobile network. UA could experiment with different mechanisms
and refine their algorithms over time.
Explicit bandwidth negotiation may need to wait for green light from
implementers. There's a risk that if initial solution is implemented
poorly, authors will be forced to use fake/exaggerated values to get
desired behavior, and that will poison the feature.
I hope that image resolution negotiation (1x/2x) may be a testbed for
bandwidth negotiation. It can be safely assumed that 2x images are
significantly larger than 1x images, so bandwidth-constrained UAs can opt
to always download 1x images.
If it turns out that this is very useful, and that 1x images are still too
large, then we may add more features for bandwidth negotiation.
Or perhaps bandwidth will increase fast enough that it won't be a
significant problem by the time implementations reach users, or maybe
high-dpi screens will become popular enough that 1x will become de-facto a
low-bandwidth version, etc.
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.
I don't understand how reliance on intrinsic size negates flexibility.
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?
I think that is a very good idea. Having option to do so is good for
performance, as it avoids reflows.
--
regards, Kornel Lesiński
