[webkit-dev] The SrcN responsive images proposal

Wed Nov 6 12:00:02 PST 2013

On Nov 6, 2013, at 10:53 AM, John Mellor <johnme at chromium.org> wrote:

> 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, 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?

I find the second syntax harder to understand than the first in addition to being more verbose. So I don't think that would be an improvement.

I know there are explanations for how src-N got to be as complex as it is. However, the following counterpoints come to mind:

(a) The complexity is not well-contained; some of it leaks out even if you want to do something very simple (e.g. cases that would be served by srcset as currently proposed).

(b) I am dubious of some of the use cases proposed as essential for src-N that ratchet up the complexity. For example, your case #2 of viewport-switching, in particular its headlining use case of a multi-column view that changes number of columns at different viewport widths, was not addressed or even meaningfully discussed in the N years that srcset and <picture> were being developed. This makes me doubt somewhat that addressing this use case is now absolutely critical. It seams kinda neat, but is it really a showstopper to address this in version 1.0 of the feature?

(c) Some of the complexity is not intrinsic to the use cases at all. Expressing a list of list syntax where one level of the list is implicit in numbered attribute names and the other level is an explicit list with comma separators is more complex than having a more unified list-of-lists syntax (for example, a microsyntax with two kinds of separators).

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

There are, however, places in the platform that take an image URL and which are not in CSS. For example, video at poster and input at src. These are probably obscure enough that they don't need to be addressed in v1 of the feature, but it would make sense to address them eventually, and having less attribute surface area for the solution would help. (I don't think this is intrinsic to the solution though.)

Regards,
Maciej

> 
> 
> 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
> 
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20131106/3a8b32df/attachment.html>