[whatwg] Features for responsive Web design

[Glenn Maynard]

On Tue, May 15, 2012 at 2:28 AM, Ian Hickson <ian at hixie.ch> wrote:

> Now I'm not sure what to do about the bandwidth one. It's very hard for a
> user agent to estimate its bandwidth availability -- it depends on the
> server, and the network location of the server, almost as much as on the
> location of the client; it depends on the current network congestion, it
> ...
>

It's tricky, but not necessarily impossible.  Brainstorming a bit, it could
be useful to specify the file size, eg.

  <img srcset="
       face-1900-1200 at HQ.jpeg 1900w 1200h 2500000b,
        face-1900-1200 at MQ.jpeg 1900w 1200h 1500000b,
        face-1900-1200 at LQ.jpeg 1900w 1200h  500000b,
   ">

where the images are, say, JPEG q12, q10 and q4.  This allows the browser
to save bandwidth with a much lower quality loss than you'd see by using a
lower-resolution image.  (In principle, it could also download the LQ
version first, then after the rest of the site has loaded and the page is
usable, go back and start downloading a better version, replacing the image
in-place invisibly to scripts.  You sort-of get this with progressive
JPEGs, but you can't get any control over it with HTTP.)  This assumes the
image quality is roughly linearly comparable; it probably wouldn't make
sense to mix JPEG and PNG images like this.

The heuristics for figuring out which size to use would be up to
implementations.  For example, if historical network statistics tell you
your connection is at best 100k/sec, you probably don't want the HQ image;
if you're at 3 MB/sec, the HQ one is probably fine.

It might be that this is too hard a problem to ever work well enough to be
useful--that is, if you think the QoI will never actually be good enough.

-- 
Glenn Maynard