<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="gmail_quote">On Wed, Nov 6, 2013 at 8:00 PM, Maciej Stachowiak <span dir="ltr">&lt;<a href="mailto:mjs@apple.com" target="_blank">mjs@apple.com</a>&gt;</span> wrote:<br>

</div></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div style="word-wrap:break-word"><div><div>(...)</div><div><br></div><div>I know there are explanations for how src-N got to be as complex as it is. However, the following counterpoints come to mind:<br></div><div><br></div>

<div>(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).</div></div></div></blockquote><div><br></div>

<div class="gmail_extra"><div class="gmail_quote"><div class="gmail_quote">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:</div>

</div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><div class="gmail_quote"><font face="courier new, monospace">srcset=&quot;xs.png </font><span style="font-family:&#39;courier new&#39;,monospace">400w </span><span style="font-family:&#39;courier new&#39;,monospace">.5x, s.png </span><span style="font-family:&#39;courier new&#39;,monospace">400w </span><span style="font-family:&#39;courier new&#39;,monospace">1x, m.png </span><span style="font-family:&#39;courier new&#39;,monospace">400w </span><span style="font-family:&#39;courier new&#39;,monospace">2x,</span></div>

<div class="gmail_quote"><font face="courier new, monospace">        s.png 8</font><span style="font-family:&#39;courier new&#39;,monospace">00w </span><span style="font-family:&#39;courier new&#39;,monospace">.5x, m.png </span><font face="courier new, monospace">8</font><span style="font-family:&#39;courier new&#39;,monospace">00w </span><span style="font-family:&#39;courier new&#39;,monospace">1x, l.png </span><font face="courier new, monospace">8</font><span style="font-family:&#39;courier new&#39;,monospace">00w </span><span style="font-family:&#39;courier new&#39;,monospace">2x,</span></div>

<div class="gmail_quote"><font face="courier new, monospace">        m.png 1600w .5x, l.png </font><span style="font-family:&#39;courier new&#39;,monospace">1600w</span><span style="font-family:&#39;courier new&#39;,monospace"> </span><span style="font-family:&#39;courier new&#39;,monospace">1x, xl.png </span><span style="font-family:&#39;courier new&#39;,monospace">1600w</span><span style="font-family:&#39;courier new&#39;,monospace"> </span><span style="font-family:&#39;courier new&#39;,monospace">2x,</span></div>

<div class="gmail_quote"><font face="courier new, monospace">        l.png .5x, xl.png 1x&quot;</font></div></div></div></blockquote><div class="gmail_extra"><div class="gmail_quote"><div class="gmail_quote">to just:</div>

<div class="gmail_quote">        <font face="courier new, monospace">src-1=&quot;100%; xs.jpg 160, s.jpg 320, m.jpg 640, l.jpg 1280, xl.jpg 2560&quot;</font></div><div class="gmail_quote"><br></div><div class="gmail_quote">

Not only is the srcN version shorter, it&#39;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.</div>

<div class="gmail_quote"><br></div><div class="gmail_quote">More complex examples are even more of a wash in favor of srcN - see how the impenetrable 985 character srcset Tab posted on <a href="http://goo.gl/8qvWg0">goo.gl/8qvWg0</a> can be reduced to an intuitively understandable 113 character src-1.</div>

<div class="gmail_quote"><br></div></div></div><div>These are not contrived examples; these are very common website layouts. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div style="word-wrap:break-word"><div><div></div><div>(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 &lt;picture&gt; 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?</div>

</div></div></blockquote><div><br></div><div>Web developers want something that works for all images. They asked <i>over and over again</i> for a solution based on the layout size of the image. Sadly that <a href="http://www.stevesouders.com/blog/2013/04/26/i/">breaks preloaders</a>, so they grudgingly switched to advocating for solutions based solely on viewport width, as it&#39;s all we&#39;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&#39;s just one convenient example of something you can do with srcN that&#39;s hard with more rigid solutions; since srcN&#39;s &lt;size-viewport-list&gt; effectively allows you to define the mapping from viewport width to layout size, it can solve any imaginable layout.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>

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

</div></div></blockquote><div><br></div><div>I&#39;ve <a href="https://lists.webkit.org/pipermail/webkit-dev/2013-November/025815.html">suggested before</a> that the attributes could be combined if that&#39;s considered simpler. My only concern is that most developers aren&#39;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...</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div class="im">

<div><br></div></div><div>(...)</div><div><br></div><div>Regards,</div><div>Maciej</div></div></div></blockquote><div><br></div>On Wed, Nov 6, 2013 at 10:33 PM, Benjamin Poulain <span dir="ltr">&lt;<a href="mailto:benjamin@webkit.org" target="_blank">benjamin@webkit.org</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On 11/6/13, 10:53 AM, John Mellor wrote:<br>

</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">Unfortunately, responsive images is a deceptively complex problem. There<br>

</div><div class="im">are 3 main use cases:<br>1. dpr-switching: fixed-width image resolution based on devicePixelRatio.<br>2. viewport-switching: flexible-width image resolution based on viewport<br>width and devicePixelRatio.<br>

3. art direction: same as #1 or #2, except additionally, must serve<br>completely different images based on viewport width.<br></div></blockquote><br>How important and common are each of those use cases?</blockquote><div>

 </div></div>1. Some images on almost every website.</div><div class="gmail_extra">2. Some images on most responsive websites.</div><div class="gmail_extra">3. Some images on some responsive websites.</div><div class="gmail_extra">

<br></div><div class="gmail_extra">Judging by the unprecedented amount of noise web developers have made about these issues, I think it&#39;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&#39;s an optional feature; sites which don&#39;t need it just use src-1 and don&#39;t have to worry about media queries at all.</div>

</div>