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

[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 at gmail.com> 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