[webkit-dev] The SrcN responsive images proposal

[John Mellor]

On Wed, Nov 6, 2013 at 8:00 PM, Maciej Stachowiak <mjs at apple.com> wrote:

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

Actually, srcN should always be at least as simple as any real world
srcset. The dpr-switching case is identical (just rename the attribute to
src-1). A simple viewport-switching case like a full-width banner changes
from:

srcset="xs.png 400w .5x, s.png 400w 1x, m.png 400w 2x,
        s.png 800w .5x, m.png 800w 1x, l.png 800w 2x,
        m.png 1600w .5x, l.png 1600w 1x, xl.png 1600w 2x,
        l.png .5x, xl.png 1x"

to just:
        src-1="100%; xs.jpg 160, s.jpg 320, m.jpg 640, l.jpg 1280, xl.jpg
2560"

Not only is the srcN version shorter, it's also much easier to author: you
just say how wide the image will be, and how wide the available image files
are, and the browser does all the error-prone maths for you.

More complex examples are even more of a wash in favor of srcN - see how
the impenetrable 985 character srcset Tab posted on goo.gl/8qvWg0 can be
reduced to an intuitively understandable 113 character src-1.

These are not contrived examples; these are very common website layouts.

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

Web developers want something that works for all images. They asked *over
and over again* for a solution based on the layout size of the image. Sadly
that breaks preloaders <http://www.stevesouders.com/blog/2013/04/26/i/>, so
they grudgingly switched to advocating for solutions based solely on
viewport width, as it's all we'd allow them. But as responsive web design
becomes increasingly dominant, variable numbers of columns is a real
problem that almost every new site encounters. And it's just one convenient
example of something you can do with srcN that's hard with more rigid
solutions; since srcN's <size-viewport-list> effectively allows you to
define the mapping from viewport width to layout size, it can solve any
imaginable layout.

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

I've suggested before<https://lists.webkit.org/pipermail/webkit-dev/2013-November/025815.html>
that
the attributes could be combined if that's considered simpler. My only
concern is that most developers aren't used to putting line breaks in html
attributes, so might feel obliged to put all the alternatives on one line,
harming readability. But as long as the developer documentation encourages
line breaks, that could be fine...


> (...)
>
> Regards,
> Maciej
>

On Wed, Nov 6, 2013 at 10:33 PM, Benjamin Poulain <benjamin at webkit.org>
 wrote:

> On 11/6/13, 10:53 AM, John Mellor wrote:
>
>> 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.
>>
>
> How important and common are each of those use cases?


1. Some images on almost every website.
2. Some images on most responsive websites.
3. Some images on some responsive websites.

Judging by the unprecedented amount of noise web developers have made about
these issues, I think it's fair to say that all 3 are important. The nice
thing about the way srcN handles art direction (multiple attributes
notwithstanding) is that it's an optional feature; sites which don't need
it just use src-1 and don't have to worry about media queries at all.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20131107/f83b1128/attachment.html>