[whatwg] Features for responsive Web design
kornel at geekhood.net
Mon May 21 21:37:56 PDT 2012
On Mon, 21 May 2012 19:36:22 -0500, Mathew Marquis <mat at matmarquis.com>
>> <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.
- MQ model of matching current state is not suited for variable thing
- 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
More information about the whatwg