W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2012

Re: [whatwg] srcset isn't future-friendly to screen size differences

From: Markus Ernst <derernst@gmx.ch>
Date: Fri, 07 Sep 2012 10:33:41 +0200
Message-ID: <5049B165.2050000@gmx.ch>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: John Mellor <johnme@chromium.org>, WHATWG List <whatwg@whatwg.org>
Am 07.09.2012 03:36 schrieb Tab Atkins Jr.:
> This email is an extension of the thread started at
> <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-August/036953.html>
> by John Mellor, distilling the core problem he has into a more
> easily-understood and digested form.
>
> The srcset attribute, as currently written, is not friendly to large
> screen-size differences that don't trigger different "art direction".
>
> Consider the following example:
>
> <img srcset="800.jpg 1x, 1600.jpg 2x" style="width: 100%; height: auto;">
>
> For a screen that's somewhere near 800px wide, this works just fine.
> However, a 1x screen 1600px wide (not too uncommon - I think a 19"
> monitor is roughly that width) will get served the 800.jpg image,
> which then gets blown up to an unattractive level.  The 1600.jpg file
> should be identical to the 800.jpg file, just higher resolution, so
> delivering it instead would be ideal, but the current syntax doesn't
> allow that, nor does it allow any reasonably reliable way for a
> browser to detect that it would be okay to serve the 1600.jpg image
> either.
>
> I'm not sure how best to solve this, but John Mellor suggested
> allowing the specification of the image's native dimensions somehow.
> That way, the browser could know that the 1600.jpg image is
> appropriate to serve as an 800px wide high-dpi image, or a 1600px wide
> low-dpi image.

With respect to the threads on responsive images of the last few months, 
IMHO it is not possible to solve both "art direction" and "bandwidth" 
use cases  with the same syntax in a satisfactory manner:

- Art direction use case: Should be controlled by the author, which is 
possible via some kind of MQ.

- Bandwidth use case: As you state above, this use case should be better 
controlled by the UA. The UA does not need MQs to make a good selection, 
but rather information on the image files available.

The problem of @srcset is that on one hand it can't convey image 
dimensions, and on the other hand it's MQ possibilities are very limited 
and not extensible if things evolve in the future. This has been 
discussed in several places of the related threads in the last few weeks.

I'd like to revive Florian Rivoal's (and my) suggestion of using 
<picture> for the art direction and @srcset for the bandwidth use case, 
so you can optimize bandwidth inside art-directed images. *But with the 
modification, that @srcset takes image dimensions rather than page 
dimensions:*

<img srcset="big.jpg 800w, normal.jpg 400w, small.jpg 200w"
    src="normal.jpg" style="width:100%">

<img srcset="16.jpg 240h, 12.jpg 180h" src="16.jpg" style="height:15em">

<picture alt="">
   <source srcset="mobile.jpg 200w, mobile-hd.jpg 400w">
   <source media="min-width: 600px"
     srcset="large.jpg 540w, larger.jpg 1080w, giant.jpg 2160w">
   <img src="mobile.jpg">
</picture>

Note that with this change there is no more "1x" default for the 
<source> element, thus a src attribute does not seem to make sense there.
Received on Friday, 7 September 2012 08:34:21 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:45 UTC