[webkit-dev] The SrcN responsive images proposal

[John Mellor]

On Sun, Oct 20, 2013 at 2:00 AM, Maciej Stachowiak <mjs at apple.com> wrote:
>
> My initial impression is that it seems a bit overengineered.

I sympathize. The issue of srcN appearing to be a complex solution to a
seemingly simple problem came up again on IRC chatting to rniwa, so I
thought I'd try to explain this briefly.

Unfortunately, responsive images is a deceptively complex problem. There
are 3 main use cases:
1. dpr-switching: fixed-width image resolution based on devicePixelRatio.
2. viewport-switching: flexible-width image resolution based on viewport
width and devicePixelRatio.
3. art direction: same as #1 or #2, except additionally, must serve
completely different images based on viewport width.

The key difference between #2 and #3, is that with #2 it's just different
resolutions of the same image, and it's desirable for browsers to be
allowed to load lower resolution variants if bandwidth is limited or
expensive, whereas with #3, the browser must strictly respect the width
breakpoint (as the image could have a different aspect ratio, so loading
the wrong one could break the layout).

srcset tackles #1 perfectly, doesn't tackle #3, and tries to tackle #2 with
the 'w' unit but that doesn't work as
intended<http://www.w3.org/community/respimg/2013/10/14/reasoning-behind-srcn-replacing-srcset-and-picture/>,
because it turns out images destined for narrower viewports are sometimes
much larger. <picture> tackles #1 and #3 but doesn't tackle #2.

srcN solves all three use cases:
1. srcN's <x-based-urls> syntax (borrowed from srcset) addresses #1.
2. srcN's <viewport-urls> syntax cleanly addresses #2.
3. Finally, srcN lets you supplement either of the above with
<media-query>'d alternatives to address #3.

It really can't be much simpler; the only simplification that could be made
without sacrificing a use case would be to scrap the <x-based-urls> syntax
for fixed-width images (which is technically redundant). Then instead of
something like the following:

<img src-1="photo at 0.5x.jpg 0.5x, photo at 1x.jpg 1x, photo at 2x.jpg 2x">

you'd have to write:

<img src-1="400px; photo at 0.5x.jpg 200, photo at 1x.jpg 400, photo at 2x.jpg 800">

where 400px is the intrinsic width of the image (and as usual in a
<viewport-urls> declaration, the alternate image urls are annotated with
the width in image pixels of the image files). This would make the syntax
consistent between use cases #1 and #2, at the expense of requiring an
extra ~8 characters for use case #1. Might be a reasonable tradeoff if it
helps people understand it?

On Wed, Nov 6, 2013 at 5:39 PM, Dean Jackson <dino at apple.com> wrote:
> Also, we should be mindful that whatever solution should be vaguely
> applicable to other contexts where you’re selecting resources based
> on resolution, etc, such as video and CSS properties. I don’t want
> an explosion of attributes everywhere, and I don’t even know how
> you’d do that in CSS (background-image-1, background-image-2, …)

CSS already has media queries, so to give it parity with srcN, you just
need to allow <viewport-urls> as an alternate syntax for image-set(),
e.g. image-set(100%;
's.jpg' 160, 'm.jpg' 320, 'l.jpg' 640)

For video, people should just do adaptive streaming using Media Source
Extensions/DASH/HLS. It's only for images that the quality of the first
frame is crucial, and yet you can't afford to wait till layout to know the
dimensions.


On Wed, Nov 6, 2013 at 5:39 PM, Dean Jackson <dino at apple.com> wrote:

>
> On 5 Nov 2013, at 9:55 am, Timothy Hatcher <timothy at apple.com> wrote:
>
> On Nov 5, 2013, at 2:18 AM, John Mellor <johnme at chromium.org> wrote:
>
> <img srcset="(min-width: 640px) 0.5x photo at 0.5x.jpg, 1x photo at 1x.jpg, 2x
> photo at 2x.jpg || 0.5x photo-crop at 0.5x.jpg, 1x photo-crop at 1x.jpg, 2x
> photo-crop at 2x.jpg">
>
>
> I prefer this over multiple attributes. It is a syntax that needs little
> explanation before you can read it and use it. It also expands the existing
> srcset instead of confusing things with other attributes.
>
> srcN is also too fiddly. If you want to add a higher precedent srcN, you
> need to reorder all the existing srcN attribute names. With srcset you just
> need to edit a single attribute's value, adding a logic operator between
> the rules.
>
>
> This is a great point.
>
> Also, we should be mindful that whatever solution should be vaguely
> applicable to other contexts where you’re selecting resources based on
> resolution, etc, such as video and CSS properties. I don’t want an
> explosion of attributes everywhere, and I don’t even know how you’d do that
> in CSS (background-image-1, background-image-2, …)
>
> Dean
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20131106/90d45fa8/attachment.html>