<img srcset> for responsive bitmapped content images

[Edward O'Connor-2]

Hi,

When authors adapt their sites for high-resolution displays such as the
iPhone's Retina display, they often need to be able to use different
assets representing the same image. Doing this for content images in
HTML is currently much more of a pain than it is in CSS (and it can be a
pain in CSS). I think we can best address this problem for bitmap[1]
content image by the addition of a srcset="" attribute to the existing
<img> element.

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.

The intrinsic size of the <img> can be computed by dividing the
intrinsic size of the actual image asset chosen with that asset's
associated scale factor. Suppose that foo-lowres.jpg is 100x100 and
foo-highres.jpg is 200x200 in the above example. If the UA chooses
foo-lowres.jpg, it computes the intrisnic size as (100/1)x(100/1) =
100x100. If the UA chooses foo-highres.jpg, it computes the intrisnic
size as (200/2)x(200/2) = 100x100.

A nice thing about this proposal is its backwards compatibility story.
Browsers which don't yet support <img srcset> will simply use the asset
referenced by <img src>. A polyfill could easily be written to check for
<img srcset> & swap out a different asset into <img src>, much like
existing libraries which check for data-fullsrc="" or the like.

Why provide a scale factor and not a media query? Well, media queries
are claims about UA state, whereas here we're asserting something about
the relationship between the image assets. Also, User Agents should be
free to use whichever asset they deem best suited to their current
situation, taking into account not just "media-queriable things" like
device resolution but also any scaling applied to the <img> with CSS,
its width="" and height="" attributes, or even things like the current
page zoom level.

Of course there are other things like bandwidth availability, data plan
usage, etc. that web developers might want to take into account when
choosing which image assets to load. This is definitely something worth
exploring. In the future we could extend the asset descriptors to cover
such cases. Something like this, maybe:

 <img srcset="foo-lowres.jpg 1x low-bandwidth,
              foo-highres.jpg 2x high-bandwidth">

I'm purposefully not making a proposal for how to describe bandwidth,
data plan usage, or such things here. Ultimately I don't think
addressing the multiple-resolution case needs to wait for a solution to
these other cases. We don't need to "SOLVE ALL THE PROBLEMS!" right now.

One downside to this proposal is that the srcset="" attribute takes a
microsyntax, and as a rule we try to avoid novel microsyntaxes in
attribute values. I think this particular microsyntax is pretty
straightforward and shouldn't cause all that much confusion for authors.

I think this is preferable to adding a suite of attributes with complex
inter-relationships, such as in Anselm Hannemann's proposal from last
August[3]. In such a proposal, we would either need to have a pre-
approved list of image scales (like Anselm's xs, s, m, l, xl), which
over-constrains designers' ability to create, or we would be introducing
user data into attribute names which—with the one exception of the
data-*="" attributes—is something I really don't think we should do.

Some have argued that we should "just use conneg" to serve the best
image. This isn't an acceptable solution for at least three reasons:

* The server doesn't have all of the relevant information needed to
  pick the best image, and sending that information with every image
  asset request is bandwidth-intensive and enables increased user
  fingerprinting.

* HTML is used in a lot of contexts, such as in EPUB, in which there's
  no server to negotiate with in the first place.[4]

* The UA should be able to "swap out" one asset for another
  transparently after the page has loaded. For instance, the UA might
  want to swap things out when the user zooms in.

I also think this approach is better than minting a new image element,
but I'll make that argument in another email.


Ted

1. "What responsive image problem? Just use SVG!" :)

2. I've proposed image-set() for CSS4 Images. Here's the relevant post
   to www-style:
     http://lists.w3.org/Archives/Public/www-style/2012Feb/1103.html
   An implementation of image-set() has recently landed in WebKit.

3. http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-August/032977.html

4. http://lists.w3.org/Archives/Public/public-html/2011May/0401.html

[Aryeh Gregor-4]

On Thu, May 10, 2012 at 10:58 AM, Edward O'Connor <eoconnor@...> 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.

[Edward O'Connor-2]

Aryeh wrote:

> 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.
[…]
> Another obvious use-case I'd like to point out is print.

Yes, these are both excellent reasons for us to adopt such a feature,
and the <img srcset> proposal can handle both cases.

> 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).

I'm not sure about this one. If a browser doesn't support SVG, I want to
be able to provide a bitmap fallback regardless of how I included the
SVG—in both the <img src> or inline <svg> element cases. <img srcset>
isn't about providing fallback, so this might best be addressed with a
different feature.

> 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.

*nod*


Thanks,
Ted

[Aryeh Gregor-4]

On Thu, May 10, 2012 at 2:44 PM, Edward O'Connor <eoconnor@...> wrote:
> I'm not sure about this one. If a browser doesn't support SVG, I want to
> be able to provide a bitmap fallback regardless of how I included the
> SVG—in both the <img src> or inline <svg> element cases. <img srcset>
> isn't about providing fallback, so this might best be addressed with a
> different feature.

There's already an easy script-free way to support fallback in inline
<svg> -- add an <img> inside some element that SVG ignores.  (I can't
remember which one is recommended, but IIRC there is one that's
suitable.)  A browser that doesn't support <svg> will ignore all the
SVG tags as unrecognized wrappers, and just display the <img>.  A
browser that supports <svg> will ignore the <img>.  There's no good
existing fallback for <img> that I know of.

In practice, any browser that supports srcset will support SVG-in-img,
and in principle vector images can be thought of as infinite-res, so
it seems like it might be a useful feature to tack on.  But this is
the weakest use-case given, I agree, and it might be best not to solve
it.

[Scott González]

You should look into the previous discussions at
http://www.w3.org/community/respimg/

There's also a prototype using media queries at
https://github.com/scottjehl/picturefill. I realize you specifically said
you think media queries don't solve all of the problems, but it seems worth
looking at.


On Thu, May 10, 2012 at 3:58 AM, Edward O'Connor <eoconnor@...> wrote:

> Hi,
>
> When authors adapt their sites for high-resolution displays such as the
> iPhone's Retina display, they often need to be able to use different
> assets representing the same image. Doing this for content images in
> HTML is currently much more of a pain than it is in CSS (and it can be a
> pain in CSS). I think we can best address this problem for bitmap[1]
> content image by the addition of a srcset="" attribute to the existing
> <img> element.
>
> 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.
>
> The intrinsic size of the <img> can be computed by dividing the
> intrinsic size of the actual image asset chosen with that asset's
> associated scale factor. Suppose that foo-lowres.jpg is 100x100 and
> foo-highres.jpg is 200x200 in the above example. If the UA chooses
> foo-lowres.jpg, it computes the intrisnic size as (100/1)x(100/1) =
> 100x100. If the UA chooses foo-highres.jpg, it computes the intrisnic
> size as (200/2)x(200/2) = 100x100.
>
> A nice thing about this proposal is its backwards compatibility story.
> Browsers which don't yet support <img srcset> will simply use the asset
> referenced by <img src>. A polyfill could easily be written to check for
> <img srcset> & swap out a different asset into <img src>, much like
> existing libraries which check for data-fullsrc="" or the like.
>
> Why provide a scale factor and not a media query? Well, media queries
> are claims about UA state, whereas here we're asserting something about
> the relationship between the image assets. Also, User Agents should be
> free to use whichever asset they deem best suited to their current
> situation, taking into account not just "media-queriable things" like
> device resolution but also any scaling applied to the <img> with CSS,
> its width="" and height="" attributes, or even things like the current
> page zoom level.
>
> Of course there are other things like bandwidth availability, data plan
> usage, etc. that web developers might want to take into account when
> choosing which image assets to load. This is definitely something worth
> exploring. In the future we could extend the asset descriptors to cover
> such cases. Something like this, maybe:
>
>  <img srcset="foo-lowres.jpg 1x low-bandwidth,
>              foo-highres.jpg 2x high-bandwidth">
>
> I'm purposefully not making a proposal for how to describe bandwidth,
> data plan usage, or such things here. Ultimately I don't think
> addressing the multiple-resolution case needs to wait for a solution to
> these other cases. We don't need to "SOLVE ALL THE PROBLEMS!" right now.
>
> One downside to this proposal is that the srcset="" attribute takes a
> microsyntax, and as a rule we try to avoid novel microsyntaxes in
> attribute values. I think this particular microsyntax is pretty
> straightforward and shouldn't cause all that much confusion for authors.
>
> I think this is preferable to adding a suite of attributes with complex
> inter-relationships, such as in Anselm Hannemann's proposal from last
> August[3]. In such a proposal, we would either need to have a pre-
> approved list of image scales (like Anselm's xs, s, m, l, xl), which
> over-constrains designers' ability to create, or we would be introducing
> user data into attribute names which—with the one exception of the
> data-*="" attributes—is something I really don't think we should do.
>
> Some have argued that we should "just use conneg" to serve the best
> image. This isn't an acceptable solution for at least three reasons:
>
> * The server doesn't have all of the relevant information needed to
>  pick the best image, and sending that information with every image
>  asset request is bandwidth-intensive and enables increased user
>  fingerprinting.
>
> * HTML is used in a lot of contexts, such as in EPUB, in which there's
>  no server to negotiate with in the first place.[4]
>
> * The UA should be able to "swap out" one asset for another
>  transparently after the page has loaded. For instance, the UA might
>  want to swap things out when the user zooms in.
>
> I also think this approach is better than minting a new image element,
> but I'll make that argument in another email.
>
>
> Ted
>
> 1. "What responsive image problem? Just use SVG!" :)
>
> 2. I've proposed image-set() for CSS4 Images. Here's the relevant post
>   to www-style:
>     http://lists.w3.org/Archives/Public/www-style/2012Feb/1103.html
>   An implementation of image-set() has recently landed in WebKit.
>
> 3.
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-August/032977.html
>
> 4. http://lists.w3.org/Archives/Public/public-html/2011May/0401.html
>
>

[Tab Atkins Jr.]

This proposal has a similar issue to image-set() - if the 2x means
"twice the resolution" (which it should), this will *not work by
default*.  If you make a 5 inch wide image and save it as 200dpi, when
you send it to the browser its automatic size will be 10 inches wide.
Browsers are constrained by back-compat to always display images at
96dpi.  You can get around this by explicitly setting <img width>, but
we shouldn't require that if we can avoid it.

This isn't hard to fix, of course; the fix just isn't included right now.

CSS3 Images has the image-resolution property, which lets you tell the
browser what resolution to display the image at (that is, how it
should determine the automatic size).  You can say "image-resolution:
from-image;" to get it to use the image's native resolution, whatever
it is.  So, we need to add a rule to the UA stylesheet that says
"img[srcset] { image-resolution: from-image; }".

In the closely-related case of using image-set() in CSS, we can just
have the "winning image" set the default resolution.  An earlier
version of the image() function let you set an image's resolution
immediately, but we punted it for simplicity at level 3.  This would
do the same thing.

That all said, I don't like the "2x" notation.  It's declaring "this
image's resolution is twice that of a normal image".  This has two
problems.  For one, we already have a unit that means that - the dppx
unit.  Using "2dppx" is identical to the meaning of "2x".  Since
image-set() is newer than the dppx unit, we should change it to use
<resolution> instead.

For two, I'm not sure that it's particularly obvious that when you say
"2x", you should make sure your image was saved as 196dpi.  You have
to already know what the default resolution is.  As well, I think that
values like 300dpi are pretty common, and they don't map to integral
'x' values.  If people say "screw it" and use "3x", this'll be
slightly wrong and I think will cause ugly blurring.  If we make this
take <resolution>, people can just use the dpi unit.

I agree overall that this is the right approach - declaring relevant
information to the browser and letting it decide what to do is better
than trying to set up constraints by yourself.  For example, using MQ
could result in the silly situation of downloading a high-res image at
first because you're on 4G, then throwing them away and downloading
low-res images when you drop to 2G.  Using image-set() or @srcset
would let the browser keep the images it had already downloaded.

~TJ

~TJ

[Simon Pieters-3]

On Thu, 10 May 2012 15:24:28 +0200, Tab Atkins Jr. <jackalmage@...>  
wrote:

> This proposal has a similar issue to image-set() - if the 2x means
> "twice the resolution" (which it should), this will *not work by
> default*.  If you make a 5 inch wide image and save it as 200dpi, when
> you send it to the browser its automatic size will be 10 inches wide.
> Browsers are constrained by back-compat to always display images at
> 96dpi.  You can get around this by explicitly setting <img width>, but
> we shouldn't require that if we can avoid it.
>
> This isn't hard to fix, of course; the fix just isn't included right now.

We should indeed fix it.

> CSS3 Images has the image-resolution property, which lets you tell the
> browser what resolution to display the image at (that is, how it
> should determine the automatic size).  You can say "image-resolution:
> from-image;" to get it to use the image's native resolution, whatever
> it is.  So, we need to add a rule to the UA stylesheet that says
> "img[srcset] { image-resolution: from-image; }".

Do we want from-image here? Or do authors prefer to serve 96dpi images  
that are bigger, and specify the intended dpi in the markup?

> In the closely-related case of using image-set() in CSS, we can just
> have the "winning image" set the default resolution.  An earlier
> version of the image() function let you set an image's resolution
> immediately, but we punted it for simplicity at level 3.  This would
> do the same thing.
>
> That all said, I don't like the "2x" notation.  It's declaring "this
> image's resolution is twice that of a normal image".  This has two
> problems.  For one, we already have a unit that means that - the dppx
> unit.  Using "2dppx" is identical to the meaning of "2x".  Since
> image-set() is newer than the dppx unit, we should change it to use
> <resolution> instead.
>
> For two, I'm not sure that it's particularly obvious that when you say
> "2x", you should make sure your image was saved as 196dpi.  You have
> to already know what the default resolution is.  As well, I think that
> values like 300dpi are pretty common, and they don't map to integral
> 'x' values.  If people say "screw it" and use "3x", this'll be
> slightly wrong and I think will cause ugly blurring.  If we make this
> take <resolution>, people can just use the dpi unit.

Can we just use CSS's 'dpi' instead?

<img src="default.jpg" srcset="highres.jpg 300dpi">

> I agree overall that this is the right approach - declaring relevant
> information to the browser and letting it decide what to do is better
> than trying to set up constraints by yourself.  For example, using MQ
> could result in the silly situation of downloading a high-res image at
> first because you're on 4G, then throwing them away and downloading
> low-res images when you drop to 2G.  Using image-set() or @srcset
> would let the browser keep the images it had already downloaded.

Indeed.

--
Simon Pieters
Opera Software

[Edward O'Connor-2]

Hi,

> This proposal has a similar issue to image-set() - if the 2x means
> "twice the resolution" (which it should), this will *not work by
> default*.

Just a quick update for the list—Tab and I chatted about this F2F just
now and we agree that there isn't really a problem here, so long as the
spec text is sufficiently detailed.


Ted

[Tab Atkins Jr.]

On Thu, May 10, 2012 at 3:47 PM, Simon Pieters <simonp@...> wrote:

> On Thu, 10 May 2012 15:24:28 +0200, Tab Atkins Jr. <jackalmage@...>
> wrote:
>> CSS3 Images has the image-resolution property, which lets you tell the
>> browser what resolution to display the image at (that is, how it
>> should determine the automatic size).  You can say "image-resolution:
>> from-image;" to get it to use the image's native resolution, whatever
>> it is.  So, we need to add a rule to the UA stylesheet that says
>> "img[srcset] { image-resolution: from-image; }".
>
> Do we want from-image here? Or do authors prefer to serve 96dpi images that
> are bigger, and specify the intended dpi in the markup?

Can you clarify what you mean by this?  Do you mean serving a 10inch
wide image at 96dpi rather than a 5inch wide image at 192dpi, and then
telling the browser to scale it by the x factor?

The two are identical in the image's data (they're all 960 pixels
wide), only the metadata differs.

I suspect both:
1. A lot of authors would find it very confusing if they couldn't save
an image at 300dpi and have it just work, and
2. A lot of authors will be confused to discover that that they have
to save their image as 300dpi to get it to work.

>> For two, I'm not sure that it's particularly obvious that when you say
>> "2x", you should make sure your image was saved as 196dpi.  You have
>> to already know what the default resolution is.  As well, I think that
>> values like 300dpi are pretty common, and they don't map to integral
>> 'x' values.  If people say "screw it" and use "3x", this'll be
>> slightly wrong and I think will cause ugly blurring.  If we make this
>> take <resolution>, people can just use the dpi unit.
>
> Can we just use CSS's 'dpi' instead?
>
> <img src="default.jpg" srcset="highres.jpg 300dpi">

If you take dpi, you might as well take all of the <resolution> units.
 There's only 3 so far - dpi, dpcm, and dppx.  There's no good reason
to limit to only one of them, since they're all constant multiples of
each other.

~TJ

[Mathew Marquis]

On May 10, 2012, at 9:47 AM, Simon Pieters wrote:

> On Thu, 10 May 2012 15:24:28 +0200, Tab Atkins Jr. <jackalmage@...> wrote:
>
>> This proposal has a similar issue to image-set() - if the 2x means
>> "twice the resolution" (which it should), this will *not work by
>> default*.  If you make a 5 inch wide image and save it as 200dpi, when
>> you send it to the browser its automatic size will be 10 inches wide.
>> Browsers are constrained by back-compat to always display images at
>> 96dpi.  You can get around this by explicitly setting <img width>, but
>> we shouldn't require that if we can avoid it.
>>
>> This isn't hard to fix, of course; the fix just isn't included right now.
>
> We should indeed fix it.
>
>> CSS3 Images has the image-resolution property, which lets you tell the
>> browser what resolution to display the image at (that is, how it
>> should determine the automatic size).  You can say "image-resolution:
>> from-image;" to get it to use the image's native resolution, whatever
>> it is.  So, we need to add a rule to the UA stylesheet that says
>> "img[srcset] { image-resolution: from-image; }".
>
> Do we want from-image here? Or do authors prefer to serve 96dpi images that are bigger, and specify the intended dpi in the markup?
>
>> In the closely-related case of using image-set() in CSS, we can just
>> have the "winning image" set the default resolution.  An earlier
>> version of the image() function let you set an image's resolution
>> immediately, but we punted it for simplicity at level 3.  This would
>> do the same thing.
>>
>> That all said, I don't like the "2x" notation.  It's declaring "this
>> image's resolution is twice that of a normal image".  This has two
>> problems.  For one, we already have a unit that means that - the dppx
>> unit.  Using "2dppx" is identical to the meaning of "2x".  Since
>> image-set() is newer than the dppx unit, we should change it to use
>> <resolution> instead.
>>
>> For two, I'm not sure that it's particularly obvious that when you say
>> "2x", you should make sure your image was saved as 196dpi.  You have
>> to already know what the default resolution is.  As well, I think that
>> values like 300dpi are pretty common, and they don't map to integral
>> 'x' values.  If people say "screw it" and use "3x", this'll be
>> slightly wrong and I think will cause ugly blurring.  If we make this
>> take <resolution>, people can just use the dpi unit.
>
> Can we just use CSS's 'dpi' instead?
>
> <img src="default.jpg" srcset="highres.jpg 300dpi">

Hey guys. Don’t know if it’s too early to chime in with this, but we were told by some members of the Chrome team that any browser that supports DNS prefetching — including assets — wouldn’t consider “looking-ahead” on the img tag as an option. The original src would be fetched in any case, saddling users with a redundant download.

I’ve been living and breathing this topic in the Responsive Images Community Group for months now, so I’m psyched to see the problem getting some attention!

>
>> I agree overall that this is the right approach - declaring relevant
>> information to the browser and letting it decide what to do is better
>> than trying to set up constraints by yourself.  For example, using MQ
>> could result in the silly situation of downloading a high-res image at
>> first because you're on 4G, then throwing them away and downloading
>> low-res images when you drop to 2G.  Using image-set() or @srcset
>> would let the browser keep the images it had already downloaded.
>
> Indeed.
>
> --
> Simon Pieters
> Opera Software

[Boris Zbarsky]

On 5/10/12 10:19 AM, Mathew Marquis wrote:
> Hey guys. Don’t know if it’s too early to chime in with this, but we were told by some members of the Chrome team that any browser that supports DNS prefetching — including assets — wouldn’t consider “looking-ahead” on the img tag as an option.

Why not?  In any case, _DNS_ prefetching would be the same for both the
low-res and high-res image, I would think.

> The original src would be fetched in any case, saddling users with a redundant download.

That sounds like image prefetching, not DNS prefetching.  I see no
obvious reason it couldn't look at multiple attributes.

-Boris

[Simon Pieters-3]

On Thu, 10 May 2012 16:19:13 +0200, Tab Atkins Jr. <jackalmage@...>  
wrote:

> On Thu, May 10, 2012 at 3:47 PM, Simon Pieters <simonp@...> wrote:
>> On Thu, 10 May 2012 15:24:28 +0200, Tab Atkins Jr.  
>> <jackalmage@...>
>> wrote:
>>> CSS3 Images has the image-resolution property, which lets you tell the
>>> browser what resolution to display the image at (that is, how it
>>> should determine the automatic size).  You can say "image-resolution:
>>> from-image;" to get it to use the image's native resolution, whatever
>>> it is.  So, we need to add a rule to the UA stylesheet that says
>>> "img[srcset] { image-resolution: from-image; }".
>>
>> Do we want from-image here? Or do authors prefer to serve 96dpi images  
>> that
>> are bigger, and specify the intended dpi in the markup?
>
> Can you clarify what you mean by this?  Do you mean serving a 10inch
> wide image at 96dpi rather than a 5inch wide image at 192dpi, and then
> telling the browser to scale it by the x factor?

Yeah.

> The two are identical in the image's data (they're all 960 pixels
> wide), only the metadata differs.

Right. I gathered that from-image would use the metadata.

> I suspect both:
> 1. A lot of authors would find it very confusing if they couldn't save
> an image at 300dpi and have it just work, and

This is the situation today for <img src>, and I guess we can't change it  
now. We can provide an opt-in, though, that could also work for <img src>  
(like CSS image-resolution).

> 2. A lot of authors will be confused to discover that that they have
> to save their image as 300dpi to get it to work.

Yeah. Since the author needs to specify the resolution in the markup to  
inform the browser which image to download, we might as well use that  
information since it's more likely to be the intended dpi.

>> Can we just use CSS's 'dpi' instead?
>>
>> <img src="default.jpg" srcset="highres.jpg 300dpi">
>
> If you take dpi, you might as well take all of the <resolution> units.
>  There's only 3 so far - dpi, dpcm, and dppx.  There's no good reason
> to limit to only one of them, since they're all constant multiples of
> each other.

WFM.

--
Simon Pieters
Opera Software

[Mathew Marquis]

On May 10, 2012, at 8:36 AM, Scott González wrote:

> You should look into the previous discussions at
> http://www.w3.org/community/respimg/
>
> There's also a prototype using media queries at
> https://github.com/scottjehl/picturefill. I realize you specifically said
> you think media queries don't solve all of the problems, but it seems worth
> looking at.
>

I can’t second Scott’s suggestion enough. There is a ton of history and valuable conversation around this topic already in the Community Group, and we’ve been working with a couple of browser reps trying to get this thing solved. We’ve even gone so far as to put the solution that seems to have the most legs together as a sort-of spec, so all the details are in one easily-parsed place: https://github.com/Wilto/respimg

>
> On Thu, May 10, 2012 at 3:58 AM, Edward O'Connor <eoconnor@...> wrote:
>
>> Hi,
>>
>> When authors adapt their sites for high-resolution displays such as the
>> iPhone's Retina display, they often need to be able to use different
>> assets representing the same image. Doing this for content images in
>> HTML is currently much more of a pain than it is in CSS (and it can be a
>> pain in CSS). I think we can best address this problem for bitmap[1]
>> content image by the addition of a srcset="" attribute to the existing
>> <img> element.
>>
>> 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.
>>
>> The intrinsic size of the <img> can be computed by dividing the
>> intrinsic size of the actual image asset chosen with that asset's
>> associated scale factor. Suppose that foo-lowres.jpg is 100x100 and
>> foo-highres.jpg is 200x200 in the above example. If the UA chooses
>> foo-lowres.jpg, it computes the intrisnic size as (100/1)x(100/1) =
>> 100x100. If the UA chooses foo-highres.jpg, it computes the intrisnic
>> size as (200/2)x(200/2) = 100x100.
>>
>> A nice thing about this proposal is its backwards compatibility story.
>> Browsers which don't yet support <img srcset> will simply use the asset
>> referenced by <img src>. A polyfill could easily be written to check for
>> <img srcset> & swap out a different asset into <img src>, much like
>> existing libraries which check for data-fullsrc="" or the like.
>>
>> Why provide a scale factor and not a media query? Well, media queries
>> are claims about UA state, whereas here we're asserting something about
>> the relationship between the image assets. Also, User Agents should be
>> free to use whichever asset they deem best suited to their current
>> situation, taking into account not just "media-queriable things" like
>> device resolution but also any scaling applied to the <img> with CSS,
>> its width="" and height="" attributes, or even things like the current
>> page zoom level.
>>
>> Of course there are other things like bandwidth availability, data plan
>> usage, etc. that web developers might want to take into account when
>> choosing which image assets to load. This is definitely something worth
>> exploring. In the future we could extend the asset descriptors to cover
>> such cases. Something like this, maybe:
>>
>> <img srcset="foo-lowres.jpg 1x low-bandwidth,
>>             foo-highres.jpg 2x high-bandwidth">
>>
>> I'm purposefully not making a proposal for how to describe bandwidth,
>> data plan usage, or such things here. Ultimately I don't think
>> addressing the multiple-resolution case needs to wait for a solution to
>> these other cases. We don't need to "SOLVE ALL THE PROBLEMS!" right now.
>>
>> One downside to this proposal is that the srcset="" attribute takes a
>> microsyntax, and as a rule we try to avoid novel microsyntaxes in
>> attribute values. I think this particular microsyntax is pretty
>> straightforward and shouldn't cause all that much confusion for authors.
>>
>> I think this is preferable to adding a suite of attributes with complex
>> inter-relationships, such as in Anselm Hannemann's proposal from last
>> August[3]. In such a proposal, we would either need to have a pre-
>> approved list of image scales (like Anselm's xs, s, m, l, xl), which
>> over-constrains designers' ability to create, or we would be introducing
>> user data into attribute names which—with the one exception of the
>> data-*="" attributes—is something I really don't think we should do.
>>
>> Some have argued that we should "just use conneg" to serve the best
>> image. This isn't an acceptable solution for at least three reasons:
>>
>> * The server doesn't have all of the relevant information needed to
>> pick the best image, and sending that information with every image
>> asset request is bandwidth-intensive and enables increased user
>> fingerprinting.
>>
>> * HTML is used in a lot of contexts, such as in EPUB, in which there's
>> no server to negotiate with in the first place.[4]
>>
>> * The UA should be able to "swap out" one asset for another
>> transparently after the page has loaded. For instance, the UA might
>> want to swap things out when the user zooms in.
>>
>> I also think this approach is better than minting a new image element,
>> but I'll make that argument in another email.
>>
>>
>> Ted
>>
>> 1. "What responsive image problem? Just use SVG!" :)
>>
>> 2. I've proposed image-set() for CSS4 Images. Here's the relevant post
>>  to www-style:
>>    http://lists.w3.org/Archives/Public/www-style/2012Feb/1103.html
>>  An implementation of image-set() has recently landed in WebKit.
>>
>> 3.
>> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-August/032977.html
>>
>> 4. http://lists.w3.org/Archives/Public/public-html/2011May/0401.html
>>
>>

[Tab Atkins Jr.]

On Thu, May 10, 2012 at 4:45 PM, Mathew Marquis <mat@...> wrote:

> On May 10, 2012, at 8:36 AM, Scott González wrote:
>> You should look into the previous discussions at
>> http://www.w3.org/community/respimg/
>>
>> There's also a prototype using media queries at
>> https://github.com/scottjehl/picturefill. I realize you specifically said
>> you think media queries don't solve all of the problems, but it seems worth
>> looking at.
>>
>
> I can’t second Scott’s suggestion enough. There is a ton of history and valuable conversation around this topic already in the Community Group, and we’ve been working with a couple of browser reps trying to get this thing solved. We’ve even gone so far as to put the solution that seems to have the most legs together as a sort-of spec, so all the details are in one easily-parsed place: https://github.com/Wilto/respimg

The Responsive Images work is intended to solve a different issue than
the "send high-res versions if you have the screen and bandwidth to do
so".  It's for serving different images based on various MQ
conditions, just baked into HTML markup rather than hacking it in via
backgrounds.  MQs, though, are a fundamentally unsound method for
doing bandwidth-responsive image serving.  I gave the basic example of
why it fails in an earlier message in this thread.

~TJ

[Maciej Stachowiak]

On May 10, 2012, at 6:24 AM, Tab Atkins Jr. <jackalmage@...> wrote:

>
>
> That all said, I don't like the "2x" notation.  It's declaring "this
> image's resolution is twice that of a normal image".  This has two
> problems.  For one, we already have a unit that means that - the dppx
> unit.  Using "2dppx" is identical to the meaning of "2x".  Since
> image-set() is newer than the dppx unit, we should change it to use
> <resolution> instead.

"dppx" has the downside that not even CSS Working Group members can consistently spell it correctly.

Regards,
Maciej

[Maciej Stachowiak]

On May 10, 2012, at 6:47 AM, Simon Pieters <simonp@...> wrote:

> On Thu, 10 May 2012 15:24:28 +0200, Tab Atkins Jr. <jackalmage@...> wrote:
>
>> For two, I'm not sure that it's particularly obvious that when you say
>> "2x", you should make sure your image was saved as 196dpi.  You have
>> to already know what the default resolution is.  As well, I think that
>> values like 300dpi are pretty common, and they don't map to integral
>> 'x' values.  If people say "screw it" and use "3x", this'll be
>> slightly wrong and I think will cause ugly blurring.  If we make this
>> take <resolution>, people can just use the dpi unit.
>
> Can we just use CSS's 'dpi' instead?
>
> <img src="default.jpg" srcset="highres.jpg 300dpi">

CSS's 'dpi' is confusing, because it actually defines the ratio of device pixels to CSS inches, not device pixels to physical inches, as most users would expect 'dpi' to mean in the context of a graphics program. So 300dpi would mean the same thing as 3.125x, and would likely itself result in ugly blurring, since scaling by a fractional scale factor rarely looks crisp.

Regards,
Maciej

[Maciej Stachowiak]

On May 10, 2012, at 7:26 AM, Boris Zbarsky <bzbarsky@...> wrote:

> On 5/10/12 10:19 AM, Mathew Marquis wrote:
>> Hey guys. Don’t know if it’s too early to chime in with this, but we were told by some members of the Chrome team that any browser that supports DNS prefetching — including assets — wouldn’t consider “looking-ahead” on the img tag as an option.
>
> Why not?  In any case, _DNS_ prefetching would be the same for both the low-res and high-res image, I would think.
>
>> The original src would be fetched in any case, saddling users with a redundant download.
>
> That sounds like image prefetching, not DNS prefetching.  I see no obvious reason it couldn't look at multiple attributes.


Indeed. I'm reasonably familiar with WebKit's preloading code and I see no reason it couldn't look at the srcset attribute. This would work fine for scale factor selection. Unfortunately, it would not work for the suggestion to have srcset pick images to fit available space based on width and height. Available space is not known until layout time, which happens too late for preloading decisions. So width/height fitting would defeat prefetch, regardless of specific syntax used.

Perhaps this is what the Chrome engineers were thinking of; hard to say without more detail.

Regards,
Maciej

[Kornel Lesi�ski]

On Thu, 10 May 2012 16:02:22 +0100, Tab Atkins Jr. <jackalmage@...>  
wrote:

>> I can’t second Scott’s suggestion enough. There is a ton of history and  
>> valuable conversation around this topic already in the Community Group,  
>> and we’ve been working with a couple of browser reps trying to get this  
>> thing solved. We’ve even gone so far as to put the solution that seems  
>> to have the most legs together as a sort-of spec, so all the details  
>> are in one easily-parsed place: https://github.com/Wilto/respimg
>
> The Responsive Images work is intended to solve a different issue than
> the "send high-res versions if you have the screen and bandwidth to do
> so".  It's for serving different images based on various MQ
> conditions, just baked into HTML markup rather than hacking it in via
> backgrounds.  MQs, though, are a fundamentally unsound method for
> doing bandwidth-responsive image serving.  I gave the basic example of
> why it fails in an earlier message in this thread.

Indeed. I think there's a confusion around this in general, and  
"responsive images" mean different things to different people.

While the solution that Responsive Images group leans towards is  
appropriate for solving layout problems, the description of group's goals  
sounds more like solving optimisation/dpi problems. I think these are  
orthogonal issues and both of them may be worth solving.


I've tried to sort problems/use-cases here:

http://www.w3.org/community/respimg/2012/04/16/summary-of-use-cases-and-requirements/

--
regards, Kornel Lesiński

[Kornel Lesi�ski]

On Thu, 10 May 2012 21:18:41 +0100, Maciej Stachowiak <mjs@...>  
wrote:

>>> For two, I'm not sure that it's particularly obvious that when you say
>>> "2x", you should make sure your image was saved as 196dpi.  You have
>>> to already know what the default resolution is.  As well, I think that
>>> values like 300dpi are pretty common, and they don't map to integral
>>> 'x' values.  If people say "screw it" and use "3x", this'll be
>>> slightly wrong and I think will cause ugly blurring.  If we make this
>>> take <resolution>, people can just use the dpi unit.
>>
>> Can we just use CSS's 'dpi' instead?
>>
>> <img src="default.jpg" srcset="highres.jpg 300dpi">
>
> CSS's 'dpi' is confusing, because it actually defines the ratio of  
> device pixels to CSS inches, not device pixels to physical inches, as  
> most users would expect 'dpi' to mean in the context of a graphics  
> program. So 300dpi would mean the same thing as 3.125x, and would likely  
> itself result in ugly blurring, since scaling by a fractional scale  
> factor rarely looks crisp.

I doubt whether support for non-integer scale factors/arbitrary DPI is  
going to be useful in practice.

While it's relatively easy to resize photos for any DPI, it's not  
desirable from caching/processing perspective (hosting and serving as many  
different variants of a file as there are screen densities). A pragmatic  
solution is to have few sizes and serve a good enough size, which may as  
well be integer multiplies of a CSS pixel.

And when it's important to serve pixel-perfect images for arbitrary DPI,  
then probably it's equally important to have pixel-perfect CSS as well.  
Unfortunately, it's very hard to write device-pixel-perfect CSS for  
non-integer multiplies of a CSS pixel. I don't expect many (if any)  
authors to actually write `border: 0.6024096386px solid` to achieve this.

Most artists won't spend time to prepare dozens of pixel-perfect manually  
resized versions of icons for varying screen densities, so most of the  
time assets for resolutions between 1x and maximum will be automatically  
resized one way or another.

Therefore, I expect browsers/systems to continue using fake 96dpi/192dpi  
snapped to device pixels, and artists to focus only on those ratios. It's  
simplest for everybody and gives device-pixel-perfect rendering on varying  
screen densities.

--
regards, Kornel Lesiński

[Julian Reschke]

On 2012-05-10 09:58, Edward O'Connor wrote:

> Hi,
>
> When authors adapt their sites for high-resolution displays such as the
> iPhone's Retina display, they often need to be able to use different
> assets representing the same image. Doing this for content images in
> HTML is currently much more of a pain than it is in CSS (and it can be a
> pain in CSS). I think we can best address this problem for bitmap[1]
> content image by the addition of a srcset="" attribute to the existing
> <img>  element.
>
> 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.">
> ...

Inventing a new microsyntax is tricky.

- "comma separated" implies you'll need to escape a comma when it
appears in a URI; this may be a problem when the URI scheme assigns a
special meaning to the comma (so it doesn't affect HTTP but still...)

- separating URIs from parameters with whitespace implies that the URIs
are valid (in that they do not contain whitespace themselves); I
personally have no problem with that, but it should be kept in mind

Best regards, Julian