Re: [whatwg] <img srcset> for responsive bitmapped content images

On Thu, May 10, 2012 at 10:58 AM, Edward O'Connor <eoconnor@apple.com> wrote:
> The srcset="" attribute takes as its argument a simplified variant of
> the image-set() microsyntax[2]. It would look something like this:
>
> <img src="foo-lores.jpg"
>     srcset="foo-hires.jpg 2x, foo-superduperhires.jpg 6.5x"
>     alt="decent alt text for foo.">
>
> <img srcset> takes one or more comma separated image specifiers. An
> image specifier consists of a URL to an image asset and an associated
> scale factor, expressed as a number followed by the literal character
> 'x'. (The value of <img src> is treated as if it had a 1x scale
> specified, so you can avoid duplicate references to the base asset.)
>
> User Agents may make their asset selection before fetching any of the
> assets, thus avoiding multiple asset loads & the associated performance
> problems in constrained bandwidth environments.

I'd like to throw in another use-case that might be addressable by the
same feature: allowing "Save As..." to save a different version of the
image (e.g., higher-res) than is actually displayed.  Wikipedia, for
instance, often has very high-res images that get scaled down for
article viewing to save bandwidth and avoid possibly-ugly rescaling.
(At least historically, some browsers used very bad rescaling
algorithms.)  It would be nice if when users saved the image, they
saved the full-res version.  Perhaps browsers could save the
highest-res image available, rather than the one that happens to be
used for display right now.

Another obvious use-case I'd like to point out is print.  It's not
quite as trendy as the iPhone Retina display -- in fact maybe it's
getting passé :) -- but print is generally higher-res than display,
and it's common for images to appear pixelated when printing.  This
use-case might have the same requirements as the iPhone Retina
display, but it should be kept in mind in case it doesn't.

A fourth use-case I'd like to suggest is vector images.  Last I
checked, many authors don't want to serve SVG directly because too
many browsers don't support it in <img> (or at all).  Perhaps it
should be possible to specify "vector" or something in place of a
scale factor, to indicate that the image should be suitable for all
resolutions.  (A possible problem with this: very detailed SVGs can be
much larger than the equivalent bitmaps, so the bandwidth tradeoff
might not always be good.  But authors can worry about that
themselves, I guess, and not specify such vector images as possible
sources.)

It's possible that the best solution won't accommodate all of these
use-cases, but I'm just throwing them out here so that they can be
taken into account.

Received on Thursday, 10 May 2012 11:38:28 UTC