- From: Glenn Maynard <glenn@zewt.org>
- Date: Tue, 15 May 2012 13:20:40 -0500
- To: Ian Hickson <ian@hixie.ch>
- Cc: whatwg@whatwg.org
On Tue, May 15, 2012 at 2:28 AM, Ian Hickson <ian@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@HQ.jpeg 1900w 1200h 2500000b,
face-1900-1200@MQ.jpeg 1900w 1200h 1500000b,
face-1900-1200@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
Received on Tuesday, 15 May 2012 18:22:08 UTC