davidbgk
/
larlet-fr-david-cache

title: Responsive Images Done Right: A Guide To &lt;picture&gt; And srcset
url: http://www.smashingmagazine.com/2014/05/responsive-images-done-right-guide-picture-srcset/
hash_url: 0223c2efd811be0c22cec3a29bacc3e8

<p><em>On Monday, we published an <a href="http://www.smashingmagazine.com/2014/05/12/picturefill-2-0-responsive-images-and-the-perfect-polyfill/">article on Picturefill 2.0</a><sup class="po" id="note-1"><a href="#1">1</a></sup>, a perfect polyfill for responsive images. Today’s article complements Tim Wright’s article and explains exactly how we can use the upcoming &lt;picture&gt; element and srcset, with simple fallbacks for legacy browsers. There is <a href="http://timkadlec.com/2014/05/dont-wait-on-responsive-images/">no reason to wait for responsive images</a><sup class="po" id="note-2"><a href="#2">2</a></sup>; we can actually have them <a href="https://twitter.com/wilto/status/465850875102371840">very, very soon</a><sup class="po" id="note-3"><a href="#3">3</a></sup>.</em> — Ed.</p>
<blockquote>
<p>“Everything I’ve said so far could be summarized as: make pages which are adaptable.… Designing adaptable pages is designing accessible pages. And perhaps the great promise of the web, far from fulfilled as yet, is accessibility, regardless of difficulties, to information.”</p>
<p>– John Allsopp, <em><a href="http://alistapart.com/article/dao">A Dao of Web Design</a><sup class="po" id="note-4"><a href="#4">4</a></sup></em></p>
</blockquote>
<p><a href="http://www.google.com/imghp">Images</a><sup class="po" id="note-5"><a href="#5">5</a></sup> are <a href="http://mashable.com/2013/09/16/facebook-photo-uploads/">some</a><sup class="po" id="note-6"><a href="#6">6</a></sup> of the <a href="http://www.loc.gov/pictures/">most</a><sup class="po" id="note-7"><a href="#7">7</a></sup> <a href="https://www.flickr.com/commons">important</a><sup class="po" id="note-8"><a href="#8">8</a></sup> <a href="http://www.google.com/culturalinstitute/about/artproject/">pieces</a><sup class="po" id="note-9"><a href="#9">9</a></sup> of <a href="http://www.huffingtonpost.com/2012/07/10/first-photo-ever-on-the-internet-les-horribles-cernettes_n_1662823.html">information</a><sup class="po" id="note-10"><a href="#10">10</a></sup> on the <a href="http://bukk.it/look.jpg">web</a><sup class="po" id="note-11"><a href="#11">11</a></sup>, but over the web’s 25-year history, they haven’t been very adaptable at all. Everything about them has been stubbornly fixed: their size, format and crop, all set in stone by a single <code>src</code>.</p>
<p>HTML authors began to really feel these limitations when high-resolution screens and responsive layouts hit the web like a one-two punch. Authors — wanting their images to look crisp in huge layouts and on high-resolution screens — began sending larger and larger sources to everyone; the average size of an image file <a href="http://httparchive.org/trends.php?s=All&amp;minlabel=Nov+15+2010&amp;maxlabel=Apr+1+2014#bytesImg&amp;reqImg">ballooned</a><sup class="po" id="note-12"><a href="#12">12</a></sup>; very smart people called responsive web design "<a href="http://blog.cloudfour.com/css-media-query-for-mobile-is-fools-gold/">unworkably slow</a><sup class="po" id="note-13"><a href="#13">13</a></sup>".</p>
<p><strong>Images have been the number one obstacle</strong> to implementing truly adaptable and performant responsive pages — pages that scale both up and down, efficiently tailoring themselves to both the constraints and the affordances of the browsing context at hand.</p>
<p>That is about to change.</p>
<p>The latest <a href="http://picture.responsiveimages.org">specification of the <code>&lt;picture&gt;</code> element</a><sup class="po" id="note-14"><a href="#14">14</a></sup> is the result of <a href="http://www.brucelawson.co.uk/2011/notes-on-adaptive-images-yet-again/">years</a><sup class="po" id="note-15"><a href="#15">15</a></sup> (<a href="http://lists.w3.org/Archives/Public/public-html/2007Jul/0121.html">years!</a><sup class="po" id="note-16"><a href="#16">16</a></sup>) of debate on how to make images adapt. It gives authors semantic ways to group multiple versions of the same image, each version having technical characteristics that make it more or less suitable for a particular user. The new specification has achieved broad consensus and is being implemented in Chrome, Opera and Firefox (<a href="http://status.modern.ie/pictureelement">maybe even Internet Explorer!</a><sup class="po" id="note-17"><a href="#17">17</a></sup>) as I type.</p>
<p>The time to start learning this stuff is now!</p>
<p>Before we get to any of the (<em>shiny! new!</em>) markup, let’s look at the relevant ways in which browsing environments vary, i.e. the ways in which we want our images to adapt.</p>
<ol>
<li>Our images need to be able to render crisply at different <code>device-pixel-ratio</code>s. We want high-resolution screens to get high-resolution images, but we don’t want to send those images to users who wouldn’t see all of those extra pixels. Let’s call this the <code>device-pixel-ratio</code> use case.</li>
<li>If our layout is fluid (i.e. responsive), then our images will need to squish and stretch to fit it. We’ll call this fluid-image use case.</li>
<li>Note that these two use cases are closely related: To solve both, we’ll want our images to be available in multiple resolutions so that they scale efficiently. We’ll call tackling both problems simultaneously the variable-sized-image use case</li>
<li>Sometimes we’ll want to adapt our images in ways that go beyond simple scaling. We might want to crop the images or even subtly alter their content. We’ll call this the art-direction use case.</li>
<li>Finally, different browsers support different image formats. We might want to send a fancy new format such as WebP to browsers that can render it, and fall back to trusty old JPEGs in browsers that don’t. We’ll call this the type-switching use case.</li>
</ol>
<p>The new <code>&lt;picture&gt;</code> specification includes features for all of these cases. Let’s look at them one by one.</p>
<p><img src="https://media-mediatemple.netdna-ssl.com/wp-content/uploads/2014/05/viewport-selection-opt.jpg" width="500" height="245" alt="" title=""/><br/><em>Rearranging images across various resolutions is relatively easy, however, loading different images (and only them) depending on the user’s resolution is quite difficult. Well, not any more. (<a href="http://picture.responsiveimages.org/images/viewport_selection_mob_first.jpg">Image credit</a><sup class="po" id="note-18"><a href="#18">18</a></sup>)</em></p>
<h3>The <code>device-pixel-ratio</code> Use Case</h3>
<p>Let’s start simply, with a fixed-width image that we want to adapt to varying <code>device-pixel-ratio</code>s. To do this, we’ll use the first tool that the new specification gives us for grouping and describing image sources: the <code>srcset</code> attribute.</p>
<p>Say we have two versions of an image:</p>
<ul>
<li><code>small.jpg</code> (320 × 240 pixels)</li>
<li><code>large.jpg</code> (640 × 480 pixels)</li>
</ul>
<p>We want to send <code>large.jpg</code> only to users with high-resolution screens. Using <code>srcset</code>, we’d mark up our image like so:</p>
<pre><code class="language-markup">&lt;img srcset="small.jpg 1x, large.jpg 2x"&#13;
   src="small.jpg"&#13;
   alt="A rad wolf" /&gt;&#13;
</code></pre>
<p>The <code>srcset</code> attribute takes a comma-separated list of image URLs, each with an <code>x</code> descriptor stating the <code>device-pixel-ratio</code> that that file is intended for.</p>
<p>The <code>src</code> is there for browsers that don’t understand <code>srcset</code>. The <code>alt</code>, of course, is included for browsers that don’t render images at all. One element and three attributes gets us an image that looks crisp on high-resolution devices and efficiently degrades all the way down to text. Not too shabby!</p>
<h3 id="the-fluid-and-variable-sized-image-use-cases">The Fluid- And Variable-Sized-Image Use Cases <a href="#the-fluid-and-variable-sized-image-use-cases" aria-label="Link to section 'The Fluid- And Variable-Sized-Image Use Cases'" class="sr hsl">Link</a></h3>
<p>What that markup won’t do is efficiently squish and stretch our image in a fluid layout. Before addressing this fluid-image use case, we need a little background on how browsers work.</p>
<p>Image preloading is, according to Steve Souders, “<a href="http://www.stevesouders.com/blog/2013/04/26/i/">the single biggest performance improvement browsers have ever made</a><sup class="po" id="note-19"><a href="#19">19</a></sup>.” Images are often the heaviest elements on a page; loading them ASAP is in everyone’s best interest. Thus, the first thing a browser will do with a page is scan the HTML for image URLs and begin loading them. The browser does this long before it has constructed a DOM, loaded external CSS or painted a layout. Solving the fluid-image use case is tricky, then; we need the browser to pick a source before it knows the image’s rendered size.</p>
<p><strong>What a browser does know at all times is the environment it’s rendering in</strong>: the size of the viewport, the resolution of the user’s screen, that sort of thing. We use this information when we use media queries, which tailor our layouts to fit particular browsing environments.</p>
<p>Thus, to get around the preloading problem, the first <a href="http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/035855.html">proposals</a><sup class="po" id="note-20"><a href="#20">20</a></sup> for fluid-image <a href="http://alistapart.com/article/responsive-images-how-they-almost-worked-and-what-we-need">features</a><sup class="po" id="note-21"><a href="#21">21</a></sup> suggested attaching media queries to sources. We would base our source-picking mechanism on the size of the viewport, which the browser knows at picking-time, not on the final rendered size of the image, which it doesn’t.</p>
<p><a href="http://ericportis.com/posts/2014/srcset-sizes/"><img src="https://media-mediatemple.netdna-ssl.com/wp-content/uploads/2014/05/measuring-image-size.png" width="500" height="340" alt="" title=""/></a><sup class="po" id="note-22"><a href="#22">22</a></sup><br/><em>Dealing with responsive images turned out to be quite a nightmare. A better way to provide the browser with details about its environment is by simply telling the browser the rendered size of the image. Kind of obvious, really. (<a href="http://ericportis.com/posts/2014/srcset-sizes/">Image credit</a><sup class="po" id="note-23"><a href="#23">23</a></sup>)</em></p>
<p>As it <a href="http://ericportis.com/posts/2014/srcset-sizes/">turns out</a><sup class="po" id="note-24"><a href="#24">24</a></sup>, that’s a bad idea. While it’s technically workable, calculating the media queries needed is tedious and error-prone. A better idea is to <strong>simply tell the browser the rendered size of the image</strong>!</p>
<p>Once we tell the browser how many pixels it <em>needs</em> (via a new attribute, <code>sizes</code>) and how many pixels each of the sources <em>has</em> (via <code>w</code> descriptors in <code>srcset</code>), picking a source becomes trivial. The browser picks the smallest source that will still look reasonably crisp within its container.</p>
<p>Let’s make this concrete by developing our previous example. Suppose we now have three versions of our image:</p>
<ul>
<li><code>large.jpg</code> (1024 × 768 pixels)</li>
<li><code>medium.jpg</code> (640 × 480 pixels)</li>
<li><code>small.jpg</code> (320 × 240 pixels)</li>
</ul>
<p>And we want to place these in a flexible grid — a grid that starts out as a single column but switches to three columns in larger viewports, <a href="http://ericportis.com/etc/smashing-mag-picture-examples/variable-size.html">like this</a><sup class="po" id="note-25"><a href="#25">25</a></sup>:</p>
<p><a href="http://ericportis.com/etc/smashing-mag-picture-examples/variable-size.html"><img src="https://media-mediatemple.netdna-ssl.com/wp-content/uploads/2014/05/wolves-picture-examples-opt.png" width="500" height="310" alt="" title=""/></a><sup class="po" id="note-26"><a href="#26">26</a></sup><br/><em>A responsive grid example. (<a href="http://ericportis.com/etc/smashing-mag-picture-examples/variable-size.html">See the demo</a><sup class="po" id="note-27"><a href="#27">27</a></sup>)</em></p>
<p>Here’s how we’d mark it up:</p>
<pre><code class="language-markup">&lt;img srcset="large.jpg  1024w,&#13;
      medium.jpg 640w,&#13;
      small.jpg  320w"&#13;
   sizes="(min-width: 36em) 33.3vw,&#13;
      100vw"&#13;
   src="small.jpg"&#13;
   alt="A rad wolf" /&gt;&#13;
</code></pre>
<p>We’re using <code>srcset</code> again, but instead of <code>x</code> descriptors, we’re attaching <code>w</code> descriptors to our sources. These describe the actual width, in pixels, of the referenced file. So, if you “Save for Web…” at 1024 × 768 pixels, then mark up that source in <code>srcset</code> as <code>1024w</code>.</p>
<p>You’ll note that <strong>we’re specifying only image widths</strong>. Why not heights, too? The images in our layout are width-constrained; their widths are set explicitly by the CSS, but their heights are not. The vast majority of responsive images in the wild are width-constrained, too, so the specification keeps things simple by dealing only in widths. There are some <a href="https://github.com/ResponsiveImagesCG/picture-element/issues/85">good</a><sup class="po" id="note-28"><a href="#28">28</a></sup> <a href="https://github.com/ResponsiveImagesCG/picture-element/issues/86">reasons</a><sup class="po" id="note-29"><a href="#29">29</a></sup> for including heights, too — but not yet.</p>
<p>So, that’s <code>w</code> in <code>srcset</code>, which describes how many pixels each of our sources <em>has</em>. Next up, the <code>sizes</code> attribute. The <code>sizes</code> attribute tells the browser how many pixels it <em>needs</em> by describing the final rendered width of our image. Think of <code>sizes</code> as a way to give the browser a bit of information about the page’s layout a little ahead of time, so that it can pick a source before it has parsed or rendered any of the page’s CSS.</p>
<p>We do this by passing the browser a <a href="http://www.w3.org/TR/css3-values/#lengths">CSS length</a><sup class="po" id="note-30"><a href="#30">30</a></sup> that describes the image’s rendered width. CSS lengths can be either absolute (for example, <code>99px</code> or <code>16em</code>) or <a href="http://www.w3.org/TR/css3-values/#viewport-relative-lengths">relative to the viewport</a><sup class="po" id="note-31"><a href="#31">31</a></sup> (<code>33.3vw</code>, as in our example). That “relative to the viewport” part is what enables images to flex.</p>
<p>If our image occupies a third of the viewport, then our <code>sizes</code> attribute should look like this:</p>
<pre><code class="language-css">sizes="33.3vw"&#13;
</code></pre>
<p>Our example isn’t quite so simple. Our layout has a breakpoint at 36 ems. When the viewport is narrower than 36 ems, the layout changes. Below that breakpoint, the image will fill 100% of the viewport’s width. How do we encode that information in our <code>sizes</code> attribute?</p>
<p>We do it by pairing media queries with lengths:</p>
<pre><code class="language-css">sizes="(min-width: 36em) 33.3vw,&#13;
   100vw"&#13;
</code></pre>
<p>This is its format:</p>
<pre><code class="language-css">sizes="[media query] [length],&#13;
   [media query] [length],&#13;
   etc…&#13;
   [default length]"&#13;
</code></pre>
<p>The browser goes over each media query until it finds one that matches and then uses the matching query’s paired length.  If no media queries match, then the browser uses the “default” length, i.e. any length it comes across that doesn’t have a paired query.</p>
<p>With both a <code>sizes</code> length and a set of sources with <code>w</code> descriptors in <code>srcset</code> to choose from, the browser has everything it needs to efficiently load an image in a fluid, responsive layout.</p>
<p>Wonderfully, <code>sizes</code> and <code>w</code> in <code>srcset</code> also give the browser enough information to adapt the image to varying <code>device-pixel-ratio</code>s. Converting the CSS length, we give it in <code>sizes</code> to CSS pixels; and, multiplying that by the user’s <code>device-pixel-ratio</code>, the browser knows the number of device pixels it needs to fill — no matter what the user’s <code>device-pixel-ratio</code> is.</p>
<p>So, while the example in our <code>device-pixel-ratio</code> use case works only for fixed-width images and covers only 1x and 2x screens, this <code>srcset</code> and <code>sizes</code> example not only covers the fluid-image use case, but also adapts to arbitrary screen densities.</p>
<p>We’ve solved both problems at once. In the parlance set out at the beginning of this article, <code>w</code> in <code>srcset</code> and <code>sizes</code> covers the variable-sized-image use case.</p>
<p>Even more wonderfully, <strong>this markup also gives the browser some wiggle room</strong>. Attaching specific browsing conditions to sources means that the browser does its picking based on a strict set of conditions. “If the screen is high-resolution,” we say to the browser, “then you must use this source.” By simply describing the resources’ dimensions with <code>w</code> in <code>srcset</code> and the area they’ll be occupying with <code>sizes</code>, we enable the browser to apply its wealth of additional knowledge about a given user’s environment to the source-picking problem. The specification allows browsers to, say, optionally load smaller sources when bandwidth is slow or expensive.</p>
<p>One more thing. In our example, the size of the image is always a simple percentage of the viewport’s width. What if our layout combined both absolute and relative lengths by, say, adding a fixed 12-em sidebar to the three-column layout, <a href="http://ericportis.com/etc/smashing-mag-picture-examples/absolute-and-fixed.html">like this</a><sup class="po" id="note-32"><a href="#32">32</a></sup>?</p>
<p><a href="http://ericportis.com/etc/smashing-mag-picture-examples/absolute-and-fixed.html"><img src="https://media-mediatemple.netdna-ssl.com/wp-content/uploads/2014/05/absolute-relative-lengths-opt.png" width="500" height="271" alt="" title=""/></a><sup class="po" id="note-33"><a href="#33">33</a></sup><br/><em>A layout combines absolute and relative lengths. (<a href="http://ericportis.com/etc/smashing-mag-picture-examples/absolute-and-fixed.html">See the demo</a><sup class="po" id="note-34"><a href="#34">34</a></sup>)</em></p>
<p>We’d use the <a href="http://caniuse.com/calc">surprisingly well-supported</a><sup class="po" id="note-35"><a href="#35">35</a></sup> <a href="http://dev.w3.org/csswg/css-values/#calc-notation"><code>calc()</code> function</a><sup class="po" id="note-36"><a href="#36">36</a></sup> in our <code>sizes</code> attribute.</p>
<pre><code class="language-markup">sizes="(min-width: 36em) calc(.333 * (100vw - 12em)),&#13;
   100vw"&#13;
</code></pre>
<p>And… done!</p>
<p class="icad" id="cad-middle" data-ad-zone-id="97"/>
<h3 id="the-art-direction-use-case">The Art-Direction Use Case <a href="#the-art-direction-use-case" aria-label="Link to section 'The Art-Direction Use Case'" class="sr hsl">Link</a></h3>
<p>Now we’re cooking with gas! We’ve learned how to mark up varible-sized images that scale up and down efficiently, rendering crisply on any and all layouts, viewports and screens.</p>
<p>But what if we wanted to go further? What if we wanted to adapt more?</p>
<p>When Apple introduced the iPad Air last year, its website featured a <a href="http://ericportis.com/etc/ipad-air-art-direction/ipadair_hero_a.jpg">huge image of the device</a><sup class="po" id="note-37"><a href="#37">37</a></sup>. This might sound rather unremarkable, unless you — as web design geeks are wont to do — compulsively resized your browser window. When the viewport was short enough, the iPad did a remarkable thing: it <a href="http://ericportis.com/etc/ipad-air-art-direction/ipadair_hero_b.jpg">rotated to better fit the viewport</a><sup class="po" id="note-38"><a href="#38">38</a></sup>!</p>
<p>We call this sort of thing “art direction.”</p>
<p>Apple art-directed its image by abusing HTML and CSS: marking up its image — which was clearly content — as an empty <code>div</code> and switching its <code>background-image</code> with CSS. The new <code>&lt;picture&gt;</code> specification allows authors to do this sort of breakpoint-based art direction entirely in HTML.</p>
<p>The specification facilitates this by layering another method of source grouping on top of <code>srcset</code>: <code>&lt;picture&gt;</code> and <code>source</code>.</p>
<p>Let’s get back to our example. Suppose that instead of letting our image fill the full width of the viewport on small screens, we crop the image square, zooming in on the most important part of the subject, and present that small square crop at a fixed size floated off to the left, leaving a lot of space for descriptive text, <a href="http://ericportis.com/etc/smashing-mag-picture-examples/art-direction.html">like this</a><sup class="po" id="note-39"><a href="#39">39</a></sup>:</p>
<p><a href="http://ericportis.com/etc/smashing-mag-picture-examples/art-direction.html"><img src="https://media-mediatemple.netdna-ssl.com/wp-content/uploads/2014/05/wolves-descriptive-text-opt.jpg" width="500" height="392" alt="" title=""/></a><sup class="po" id="note-40"><a href="#40">40</a></sup><br/><em>An example with images combined with descriptive text. (<a href="http://ericportis.com/etc/smashing-mag-picture-examples/art-direction.html">See the demo</a><sup class="po" id="note-41"><a href="#41">41</a></sup>)</em></p>
<p>To achieve this, we’ll need a couple of additional image sources:</p>
<ul>
<li><code>cropped-small.jpg</code> (96 × 96 pixels)</li>
<li><code>cropped-large.jpg</code> (192 × 192 pixels)</li>
<li><code>small.jpg</code> (320 × 240 pixels)</li>
<li><code>medium.jpg</code> (640 × 480 pixels)</li>
<li><code>large.jpg</code> (1024 × 768 pixels)</li>
</ul>
<p>How do we mark them up? Like so:</p>
<pre><code class="language-markup">&lt;picture&gt;&#13;
   &lt;source media="(min-width: 36em)"&#13;
      srcset="large.jpg  1024w,&#13;
         medium.jpg 640w,&#13;
         small.jpg  320w"&#13;
      sizes="33.3vw" /&gt;&#13;
   &lt;source srcset="cropped-large.jpg 2x,&#13;
         cropped-small.jpg 1x" /&gt;&#13;
   &lt;img src="small.jpg" alt="A rad wolf" /&gt;&#13;
&lt;/picture&gt;&#13;
</code></pre>
<p>This example is as complex as it gets, using every feature that we’ve covered so far. Let’s break it down.</p>
<p>The <code>&lt;picture&gt;</code> element contains two <code>source</code>s and an <code>img</code>. The <code>source</code>s represent the two separate art-directed versions of the image (the square crop and the full crop). The (required) <code>img</code> serves as our fallback. As we’ll soon discover, it does much of the actual work behind the scenes.</p>
<p>First, let’s take a close look at that first <code>source</code>:</p>
<pre><code class="language-markup">&lt;source media="(min-width: 36em)"&#13;
   srcset="large.jpg  1024w,&#13;
      medium.jpg 640w,&#13;
      small.jpg  320w"&#13;
   sizes="33.3vw" /&gt;&#13;
</code></pre>
<p>This <code>source</code> represents the full uncropped version of our image. We want to show the full image only in the three-column layout — that is, when the viewport is wider than 36 ems. The first attribute here, <code>media="(min-width: 36em)"</code>, makes that happen. If a query in a <code>media</code> attribute evaluates to <code>true</code>, then the browser must use that <code>source</code>; otherwise, it’s skipped.</p>
<p>The <code>source</code>’s other two attributes — <code>srcset</code> and <code>sizes</code> — are mostly copied from our previous variable-sized-image example. One difference: Because this <code>source</code> will be chosen only for the three-column layout, our <code>sizes</code> attribute only needs a single length, <code>33.3vw</code>.</p>
<p>When the viewport is narrower than 36 ems, the first <code>source</code>’s media query will evaluate to <code>false</code>, and we’d proceed to the second:</p>
<pre><code class="language-markup">&lt;source srcset="square-large.jpg 2x,&#13;
                square-small.jpg 1x" /&gt;&#13;
</code></pre>
<p>This represents our small square crop. This version is displayed at a fixed width, but we still want it to render crisply on high-resolution screens. Thus, we’ve supplied both 1x and 2x versions and marked them up with simple <code>x</code> descriptors.</p>
<p>Lastly, we come to the surprisingly important (<em>indeed, required!</em>) <code>img</code>.</p>
<p>Any child of an <code>audio</code> or <code>video</code> element that isn’t a <code>source</code> is treated as fallback content and hidden in supporting browsers. You might, therefore, assume the same thing about the <code>img</code> here. Wrong! Users actually see the <code>img</code> element when we use <code>&lt;picture&gt;</code>. Without <code>img</code>, there’s no image; <code>&lt;picture&gt;</code> and all of its <code>source</code>s are just there to feed it a source.</p>
<p>Why? One of the main complaints about the first <code>&lt;picture&gt;</code> specification was that it reinvented the wheel, propsing an entirely new HTML media element, along the lines of <code>audio</code> and <code>video</code>, that mostly duplicated the functionality of <code>img</code>. Duplicated functionality means duplicated implementation and maintenance work — work that browser vendors weren’t keen to undertake.</p>
<p>Thus, the new specification’s reuse of <code>img</code>. The <code>&lt;picture&gt;</code> itself is invisible, a bit like a magical <code>span</code>. Its <code>source</code>s are just there for the browser to draw alternate versions of the image from. Once a source URL is chosen, that URL is fed to the <code>img</code>. Practically speaking, this means that any styles that you want to apply to your rendered image (like, say, <code>max-width: 100%</code>) need to be applied to <code>img</code>, not to <code>&lt;picture&gt;</code>.</p>
<p>OK, on to our last feature.</p>
<h3 id="the-type-switching-use-case">The Type-Switching Use Case <a href="#the-type-switching-use-case" aria-label="Link to section 'The Type-Switching Use Case'" class="sr hsl">Link</a></h3>
<p>Let’s say that, instead of doing all of this squishing, stretching and adapting to myriad viewport conditions, we simply want to give a new file format a spin and provide a fallback for non-supporting browsers. For this, we follow the pattern established by <code>audio</code> and <code>video</code>: <code>source type</code>.</p>
<pre><code class="language-markup">&lt;picture&gt;&#13;
   &lt;source type="image/svg" src="logo.svg" /&gt;&#13;
   &lt;source type="image/png" src="logo.png" /&gt;&#13;
   &lt;img src="logo.gif" alt="RadWolf, Inc." /&gt;&#13;
&lt;/picture&gt;&#13;
</code></pre>
<p>If the browser doesn’t understand the <code>image/svg</code> <a href="http://en.wikipedia.org/wiki/Internet_media_type">media type</a><sup class="po" id="note-42"><a href="#42">42</a></sup>, then it skips the first <code>source</code>; if it can’t make heads or tails of <code>image/png</code>, then it falls back to <code>img</code> and the GIF.</p>
<p>During the <a href="http://alistapart.com/article/pngopacity">extremely painful GIF-to-PNG transition</a><sup class="po" id="note-43"><a href="#43">43</a></sup> period, web designers would have killed for such a feature. The <code>&lt;picture&gt;</code> element gives it to us, setting the stage for new image formats to be easily adopted in the years to come.</p>
<h3 id="thats-it">That’s It! <a href="#thats-it" aria-label="Link to section 'That’s It!'" class="sr hsl">Link</a></h3>
<p>That’s everything: every feature in the new <code>&lt;picture&gt;</code> specification and the rationale behind each. All in all, <code>srcset</code>, <code>x</code>, <code>w</code>, <code>sizes</code>, <code>&lt;picture&gt;</code>, <code>source</code>, <code>media</code> and <code>type</code> give us a rich set of tools with which to make images truly adaptable — images that can (<em>finally!</em>) flow efficiently in flexible layouts and a wide range of devices.</p>
<p><strong>The specification is not yet final</strong>. The first implementations are in progress and are being staged behind experimental flags; its implementors and authors are working together to hash out the specification’s finer details on a daily basis. All of this is happening under the umbrella of the <a href="http://responsiveimages.org">Responsive Images Community Group</a><sup class="po" id="note-44"><a href="#44">44</a></sup>. If you’re interested in following along, <a href="http://www.w3.org/community/respimg/">join</a><sup class="po" id="note-45"><a href="#45">45</a></sup> the group, drop in on the <a href="http://irc.lc/w3c/respimg/newb">IRC channel</a><sup class="po" id="note-46"><a href="#46">46</a></sup>, weigh in on a <a href="https://github.com/ResponsiveImagesCG/picture-element/issues">GitHub issue</a><sup class="po" id="note-47"><a href="#47">47</a></sup> or file a new one, sign up for the <a href="http://responsiveimages.org">newsletter</a><sup class="po" id="note-48"><a href="#48">48</a></sup>, or follow the RICG <a href="http://www.twitter.com/respimg">on Twitter</a><sup class="po" id="note-49"><a href="#49">49</a></sup>.
</p><p><em>(il, al)</em></p>
<ol class="po"><li id="#1"><a href="#note-1">1 http://www.smashingmagazine.com/2014/05/12/picturefill-2-0-responsive-images-and-the-perfect-polyfill/</a></li><li id="#2"><a href="#note-2">2 http://timkadlec.com/2014/05/dont-wait-on-responsive-images/</a></li><li id="#3"><a href="#note-3">3 https://twitter.com/wilto/status/465850875102371840</a></li><li id="#4"><a href="#note-4">4 http://alistapart.com/article/dao</a></li><li id="#5"><a href="#note-5">5 http://www.google.com/imghp</a></li><li id="#6"><a href="#note-6">6 http://mashable.com/2013/09/16/facebook-photo-uploads/</a></li><li id="#7"><a href="#note-7">7 http://www.loc.gov/pictures/</a></li><li id="#8"><a href="#note-8">8 https://www.flickr.com/commons</a></li><li id="#9"><a href="#note-9">9 http://www.google.com/culturalinstitute/about/artproject/</a></li><li id="#10"><a href="#note-10">10 http://www.huffingtonpost.com/2012/07/10/first-photo-ever-on-the-internet-les-horribles-cernettes_n_1662823.html</a></li><li id="#11"><a href="#note-11">11 http://bukk.it/look.jpg</a></li><li id="#12"><a href="#note-12">12 http://httparchive.org/trends.php?s=All&amp;minlabel=Nov+15+2010&amp;maxlabel=Apr+1+2014#bytesImg&amp;reqImg</a></li><li id="#13"><a href="#note-13">13 http://blog.cloudfour.com/css-media-query-for-mobile-is-fools-gold/</a></li><li id="#14"><a href="#note-14">14 http://picture.responsiveimages.org</a></li><li id="#15"><a href="#note-15">15 http://www.brucelawson.co.uk/2011/notes-on-adaptive-images-yet-again/</a></li><li id="#16"><a href="#note-16">16 http://lists.w3.org/Archives/Public/public-html/2007Jul/0121.html</a></li><li id="#17"><a href="#note-17">17 http://status.modern.ie/pictureelement</a></li><li id="#18"><a href="#note-18">18 http://picture.responsiveimages.org/images/viewport_selection_mob_first.jpg</a></li><li id="#19"><a href="#note-19">19 http://www.stevesouders.com/blog/2013/04/26/i/</a></li><li id="#20"><a href="#note-20">20 http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/035855.html</a></li><li id="#21"><a href="#note-21">21 http://alistapart.com/article/responsive-images-how-they-almost-worked-and-what-we-need</a></li><li id="#22"><a href="#note-22">22 http://ericportis.com/posts/2014/srcset-sizes/</a></li><li id="#23"><a href="#note-23">23 http://ericportis.com/posts/2014/srcset-sizes/</a></li><li id="#24"><a href="#note-24">24 http://ericportis.com/posts/2014/srcset-sizes/</a></li><li id="#25"><a href="#note-25">25 http://ericportis.com/etc/smashing-mag-picture-examples/variable-size.html</a></li><li id="#26"><a href="#note-26">26 http://ericportis.com/etc/smashing-mag-picture-examples/variable-size.html</a></li><li id="#27"><a href="#note-27">27 http://ericportis.com/etc/smashing-mag-picture-examples/variable-size.html</a></li><li id="#28"><a href="#note-28">28 https://github.com/ResponsiveImagesCG/picture-element/issues/85</a></li><li id="#29"><a href="#note-29">29 https://github.com/ResponsiveImagesCG/picture-element/issues/86</a></li><li id="#30"><a href="#note-30">30 http://www.w3.org/TR/css3-values/#lengths</a></li><li id="#31"><a href="#note-31">31 http://www.w3.org/TR/css3-values/#viewport-relative-lengths</a></li><li id="#32"><a href="#note-32">32 http://ericportis.com/etc/smashing-mag-picture-examples/absolute-and-fixed.html</a></li><li id="#33"><a href="#note-33">33 http://ericportis.com/etc/smashing-mag-picture-examples/absolute-and-fixed.html</a></li><li id="#34"><a href="#note-34">34 http://ericportis.com/etc/smashing-mag-picture-examples/absolute-and-fixed.html</a></li><li id="#35"><a href="#note-35">35 http://caniuse.com/calc</a></li><li id="#36"><a href="#note-36">36 http://dev.w3.org/csswg/css-values/#calc-notation</a></li><li id="#37"><a href="#note-37">37 http://ericportis.com/etc/ipad-air-art-direction/ipadair_hero_a.jpg</a></li><li id="#38"><a href="#note-38">38 http://ericportis.com/etc/ipad-air-art-direction/ipadair_hero_b.jpg</a></li><li id="#39"><a href="#note-39">39 http://ericportis.com/etc/smashing-mag-picture-examples/art-direction.html</a></li><li id="#40"><a href="#note-40">40 http://ericportis.com/etc/smashing-mag-picture-examples/art-direction.html</a></li><li id="#41"><a href="#note-41">41 http://ericportis.com/etc/smashing-mag-picture-examples/art-direction.html</a></li><li id="#42"><a href="#note-42">42 http://en.wikipedia.org/wiki/Internet_media_type</a></li><li id="#43"><a href="#note-43">43 http://alistapart.com/article/pngopacity</a></li><li id="#44"><a href="#note-44">44 http://responsiveimages.org</a></li><li id="#45"><a href="#note-45">45 http://www.w3.org/community/respimg/</a></li><li id="#46"><a href="#note-46">46 http://irc.lc/w3c/respimg/newb</a></li><li id="#47"><a href="#note-47">47 https://github.com/ResponsiveImagesCG/picture-element/issues</a></li><li id="#48"><a href="#note-48">48 http://responsiveimages.org</a></li><li id="#49"><a href="#note-49">49 http://www.twitter.com/respimg</a></li></ol>