Re: [whatwg] Features for responsive Web design

On Mon, 21 May 2012 19:36:22 -0500, Mathew Marquis <mat@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

Received on Tuesday, 22 May 2012 04:38:52 UTC