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

[Adam Barth]

On Tue, Nov 12, 2013 at 10:45 AM, John Mellor <johnme at google.com> wrote:
> On Tue, Nov 12, 2013 at 5:50 PM, Adam Barth <w3c at 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.

Why doesn't it support variable-sized images?  In example above, one
of the cases is 30x30 and the other is 60x60.  Maybe I've
misunderstood what you mean by variable-sized images?

> - Requires you to know the intrinsic aspect ratio of the images in advance.

That seems like something we should improve about CSS more generally.

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

These seem like minor concerns compared to the cost of inventing new
HTML elements, attribute, and semantics.

> On Tue, Nov 12, 2013 at 5:50 PM, Adam Barth <w3c at 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).

No user agents support src-N or <picture>, so we're already ahead of
the game.  :)

> 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:
>
> <style>
> .photo {
>     image-width: 100%;
> }
> </style>
>
> <img class="photo" srcs="160.jpg 160, 320.jpg 320, 640.jpg 640, 1280.jpg
> 1280, 2560.jpg 2560">
>
> (and as in src-N, 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:
>
> <style>
> .photo {
>     image-width: 128px;
> }
> </style>
>
> <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
> image)
>
> If you have art direction and dpr-switching, it'd be:
>
> <style>
> .photo {
>     image-width: "small" 128px;
> }
> @media (min-width: 20em) {
> .photo {
>     image-width: "big" 400px;
> }
> }
> </style>
>
> <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.

These proposals all invent new syntax and semantics.  I'd much rather
start with an approach that doesn't introduce new syntax or semantics
and just makes the web faster by optimizing existing content.

> My main concern is that authors won't realise that the CSS must be inlined;
> I'm not sure how to make that foolproof.

We'll have to write tutorials and the like.  All these proposals have
a developer education component.  Developers won't magically know how
to use src-N either.

Adam