W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2013

Re: [whatwg] <imgset> responsive imgs proposition (Re: The src-N proposal)

From: John Mellor <johnme@google.com>
Date: Tue, 12 Nov 2013 18:45:36 +0000
Message-ID: <CAG_kaUb927KHt5Fp33SyzD+AoH9+1=q3GCxt_0h+SYMBTurmXw@mail.gmail.com>
To: Adam Barth <w3c@adambarth.com>
Cc: "Jukka K. Korpela" <jkorpela@cs.tut.fi>, Markus Ernst <derernst@gmx.ch>, whatwg <whatwg@lists.whatwg.org>, Markus Lanthaler <markus.lanthaler@gmx.net>, Ryosuke Niwa <rniwa@apple.com>
On Tue, Nov 12, 2013 at 5:50 PM, Adam Barth <w3c@adambarth.com> wrote:

> We might even be able to make this work without inventing anything:
> <style type="text/css">
> @media (min-width: 480px) {
>   .artdirected {
>     width: 30px;
>     height: 30px;
>     background-image: image-set(url(small.png) 1x, url(small-hires.png)
> 2x);
>  }
> }
> @media (min-width: 600px) {
>   .artdirected {
>     width: 60px;
>     height: 60px;
>     background-image: image-set(url(large.png) 1x, url(large-hires.png)
> 2x);
>  }
> }
> </style>
> <div class="artdirected"></div>

Three downsides to that:
- Doesn't address viewport-switching (variable-sized images), though we may
be able to fix that by extending image-set to support src-N's
<viewport-urls> syntax.
- Requires you to know the intrinsic aspect ratio of the images in advance.
- Slightly less semantic (can't include an alt attribute, etc).
- Most sites will end up just referencing all their images by #id, which is
fairly icky. Since we're inlining the presentation into the content anyway,
may as well inline it next to the relevant bit of the content.

On Tue, Nov 12, 2013 at 5:50 PM, Adam Barth <w3c@adambarth.com> wrote:

> What's most attractive to me about this approach is that it doesn't
> require inventing anything new, which means the compatibility story
> for older user agents is solid.  You don't need a polyfill or anything
> like that.

Except that most user agents don't support image-set yet (only Chrome and
Safari 6+ IIRC).


If we did want to split src-N up to separate presentation from content,
you'd probably want to put the <size-viewport-list> and <media-query>s into
inline CSS, and leave just the <size-based-urls> (which are pure content)
in the HTML. Then you'd end up with something like the following.

If you just have viewport-switching (and dpr-switching), it'd be:

.photo {
    image-width: 100%;

<img class="photo" srcs="160.jpg 160, 320.jpg 320, 640.jpg 640, 1280.jpg
1280, 2560.jpg 2560">

(and as in src-N<http://tabatkins.github.io/specs/respimg/Overview.html#viewport>,
you could use more complicated <size-viewport-list> expressions like "100%
(30em) 50% (50em) 33%" if the image width is a non-linear function of
viewport width)

If you just have dpr-switching (fixed-width images), it'd be:

.photo {
    image-width: 128px;

<img class="photo" srcs="64.jpg 64, 128.jpg 128, 256.jpg 256">

(where the ratio between the widths of the available images, and the
image-width from CSS, is used to calculate the density of each available

If you have art direction and dpr-switching, it'd be:

.photo {
    image-width: "small" 128px;
@media (min-width: 20em) {
.photo {
    image-width: "big" 400px;

<img class="photo"
     srcs-small="s64.jpg 64, s128.jpg 128, s256.jpg 256"
     srcs-big="b200.jpg 200, b400.jpg 400, b800.jpg 800">

(here the author has assigned names to each of their art direction cases
[optional if you only have one case], and provides an alternate list of
image srcs for each case)

This actually looks pretty reasonable (and unlike earlier proposals in this
thread, covers all use cases). One nice benefit over src-N is that
the <size-viewport-list> -- i.e. "128px" or "100%" or "100% (30em) 50%
(50em) 33%" -- doesn't get repeated for every image, if there are several
images with the same relationship between viewport size and image size.

My main concern is that authors won't realise that the CSS must be inlined;
I'm not sure how to make that foolproof.
Received on Tuesday, 12 November 2013 18:46:16 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:14 UTC