[whatwg] img srcset / css image-set issues

[John Mellor]

On Wed, Aug 22, 2012 at 5:19 PM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:

> On Wed, Aug 22, 2012 at 4:22 AM, John Mellor <johnme at chromium.org> wrote:
> > On Wednesday, August 22, 2012, Tab Atkins Jr. wrote:
> >> Let's assume that, instead, you're trying to serve two versions of the
> >> image: one for small screens and one for larger screens, and each
> >> version has two resolutions.  In that case, you'd do this:
> >>
> >> <img style="width:100%" srcset="320.jpg 1x 320w, 640.jpg 2x 320w,
> >> 1280.jpg 1x, 2560.jpg 2x">
> >
> >
> > But that doesn't work! Let's look at some common devices for which it
> fails:
> >
> >     360w 2x portrait Galaxy S III => 2560.jpg instead of 640.jpg!
> >     480w 1x landscape iPhone 3 => 1280.jpg instead of 640.jpg
>
> The point of the w/h descriptors is to align with your media queries
> to solve the "art direction" use-case, where different layouts may
> demand images with different sizes/ratios which may be produced
> differently (possibly generated from the same image, but with
> different layouts or whatnot).
>

But that's exactly my point! The w/h descriptors are sufficient *only* for
art direction, where you want to swap between completely different images
(or at least different crops of the same image), based on viewport size, to
match other changes occurring in your responsive design as the viewport
size changes (and they do a fine job at art direction).

They are *not* suitable (even combined with x descriptors) as a general
purpose mechanism for dealing with flexibly-sized images, where you need to
match the number of device pixels taken up by the image to the number of
image pixels in the image you load (while allowing the browser to adjust
this based on bandwidth constraints etc), since doing that properly
*requires* additional information, i.e. knowing the intrinsic size (or at
least intrinsic width or height) of the image before choosing which to
download.

If one of your breakpoints was predicated on a "max-width: 320px" MQ,
> then this is exactly what you want.  (This is probably not a great
> breakpoint, since it's clearly focused on the iPhone and likely not
> your content's actual breakpoint, but whatever.)
>
> >     2560w 1x 30" desktop => 1280.jpg instead of 2560.jpg
>
> This is adequate.  In the olden days before srcset, you'd just get the
> 1280 version all the time.  Now, if you'd like, you can toss in an
> additional breakpoint with a "2560.jpg 2560w 1x" and be fine.  It's
> not *perfectly ideal*, but it's fine.
>

No, it's not fine to just toss in an additional breakpoint. If you do this
for all important device categories you go back to the monstrous 16-entry
srcset I showed earlier, which is clearly unsustainable.


> The problem with trying to be smarter is that you have to be very
> careful to not mess with the "art direction" use-case.  It's
> *possible* to improve the syntax in the future to handle your last
> example better, but it needs to be done with care.


The art direction use case can be entirely orthogonal. It should be handled
with the w/h descriptors as currently specified. What I'm proposing would
operate after any w/h descriptors have narrowed down the set of allowable
images, and let the browser choose between the remaining images more
intelligently in the case of flexible-size images, where currently the
browser has no idea which to use.

I'm not actively working on anything right now, but my plan is to push
> for @media to be nestable inside of style blocks, so you can put the
> declarations right next to each other.
>

Cool :)