pub/NOTE_5Nov2013.html

<!DOCTYPE html>
<html lang="en" dir="ltr" typeof="bibo:Document " about="" property="dcterms:language" content="en">
<head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width,initial-scale=1">
    <title>
      Use Cases and Requirements for Standardizing Responsive Images
    </title>
    <style>
.stretchy{width: 100%;}
    @media all and (max-width: 960px){
                html{
                                                margin-left: -2.5em;
                }
    }
    @media print{
                #participantslist{
                                                display: none;
                }
                a:link,a:visited{
                                                text-decoration: none;
                                                color: inherit;
                }
    }
    </style>
    
    
  <style>/*****************************************************************
 * ReSpec 3 CSS
 * Robin Berjon - http://berjon.com/
 *****************************************************************/

/* --- INLINES --- */
em.rfc2119 { 
    text-transform:     lowercase;
    font-variant:       small-caps;
    font-style:         normal;
    color:              #900;
}

h1 acronym, h2 acronym, h3 acronym, h4 acronym, h5 acronym, h6 acronym, a acronym,
h1 abbr, h2 abbr, h3 abbr, h4 abbr, h5 abbr, h6 abbr, a abbr {
    border: none;
}

dfn {
    font-weight:    bold;
}

a.internalDFN {
    color:  inherit;
    border-bottom:  1px solid #99c;
    text-decoration:    none;
}

a.externalDFN {
    color:  inherit;
    border-bottom:  1px dotted #ccc;
    text-decoration:    none;
}

a.bibref {
    text-decoration:    none;
}

cite .bibref {
    font-style: normal;
}

code {
    color:  #ff4500;
}

/* --- TOC --- */
.toc a, .tof a {
    text-decoration:    none;
}

a .secno, a .figno {
    color:  #000;
}

ul.tof, ol.tof {
    list-style: none outside none;
}

.caption {
    margin-top: 0.5em;
    font-style:   italic;
}

/* --- TABLE --- */
table.simple {
    border-spacing: 0;
    border-collapse:    collapse;
    border-bottom:  3px solid #005a9c;
}

.simple th {
    background: #005a9c;
    color:  #fff;
    padding:    3px 5px;
    text-align: left;
}

.simple th[scope="row"] {
    background: inherit;
    color:  inherit;
    border-top: 1px solid #ddd;
}

.simple td {
    padding:    3px 10px;
    border-top: 1px solid #ddd;
}

.simple tr:nth-child(even) {
    background: #f0f6ff;
}

/* --- DL --- */
.section dd > p:first-child {
    margin-top: 0;
}

.section dd > p:last-child {
    margin-bottom: 0;
}

.section dd {
    margin-bottom:  1em;
}

.section dl.attrs dd, .section dl.eldef dd {
    margin-bottom:  0;
}
</style><style>/* --- EXAMPLES --- */
div.example-title {
    min-width: 7.5em;
    color: #b9ab2d;
}
div.example-title span {
    text-transform: uppercase;   
}
aside.example, div.example, div.illegal-example {
    padding: 0.5em;
    margin: 1em 0;
    position: relative;
    clear: both;
}
div.illegal-example { color: red }
div.illegal-example p { color: black }
aside.example, div.example {
    padding: .5em;
    border-left-width: .5em;
    border-left-style: solid;
    border-color: #e0cb52;
    background: #fcfaee;    
}

aside.example div.example {
    border-left-width: .1em;
    border-color: #999;
    background: #fff;
}
aside.example div.example div.example-title {
    color: #999;
}
</style><link href="https://www.w3.org/StyleSheets/TR/W3C-WG-NOTE" rel="stylesheet"><!--[if lt IE 9]><script src='https://www.w3.org/2008/site/js/html5shiv.js'></script><![endif]--><script src="https://raw.github.com/darobin/respec/gh-pages/js/ui/save-html.js" data-requiremodule="ui/save-html" data-requirecontext="_" async="" charset="utf-8" type="text/javascript"></script></head>
  <body id="respecDocument" role="document" class="h-entry"><div id="respecHeader" role="contentinfo" class="head">
  <p>
    
      <a href="http://www.w3.org/"><img src="https://www.w3.org/Icons/w3c_home" alt="W3C" width="72" height="48"></a>
    
  </p>
  <h1 class="title p-name" id="title" property="dcterms:title">Use Cases and Requirements for Standardizing Responsive Images</h1>
  
  <h2 id="w3c-working-group-note-05-november-2013" property="dcterms:issued" datatype="xsd:dateTime" content="2013-11-05T00:00:00.000Z"><abbr title="World Wide Web Consortium">W3C</abbr> Working Group Note <time class="dt-published" datetime="2013-11-05">05 November 2013</time></h2>
  <dl>
    
      <dt>This version:</dt>
      <dd><a class="u-url" href="http://www.w3.org/TR/2013/NOTE-respimg-usecases-20131105/">http://www.w3.org/TR/2013/NOTE-respimg-usecases-20131105/</a></dd>
      <dt>Latest published version:</dt>
      <dd><a href="http://www.w3.org/TR/respimg-usecases/">http://www.w3.org/TR/respimg-usecases/</a></dd>
    
    
      <dt>Latest editor's draft:</dt>
      <dd><a href="http://usecases.responsiveimages.org">http://usecases.responsiveimages.org</a></dd>
    
    
    
    
    
      <dt>Previous version:</dt>
      <dd><a rel="dcterms:replaces" href="http://www.w3.org/TR/2013/WD-respimg-usecases-20130226/">http://www.w3.org/TR/2013/WD-respimg-usecases-20130226/</a></dd>
    
    
    <dt>Editors:</dt>
    <dd class="p-author h-card vcard" rel="bibo:editor" inlist=""><span typeof="foaf:Person"><a class="u-url url p-name fn" rel="foaf:homepage" property="foaf:name" content="Marcos Cáceres" href="http://marcosc.com/">Marcos Cáceres</a>, <a rel="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://mozilla.com">Mozilla</a></span>
</dd>
<dd class="p-author h-card vcard" rel="bibo:editor" inlist=""><span typeof="foaf:Person"><a class="u-url url p-name fn" rel="foaf:homepage" property="foaf:name" content="Mat Marquis" href="http://matmarquis.com/">Mat Marquis</a></span>
</dd>
<dd class="p-author h-card vcard" rel="bibo:editor" inlist=""><span typeof="foaf:Person"><a class="u-url url p-name fn" rel="foaf:homepage" property="foaf:name" content="Yoav Weiss" href="http://blog.yoav.ws/">Yoav Weiss</a></span>
</dd>
<dd class="p-author h-card vcard" rel="bibo:editor" inlist=""><span typeof="foaf:Person"><a class="u-url url p-name fn" rel="foaf:homepage" property="foaf:name" content="David Newton" href="http://davidnewton.ca/">David Newton</a></span>
</dd>

    
    
      
        
          <dt>Version history:</dt>
          
             
                
                  <dd>
                    <a href="https://github.com/ResponsiveImagesCG/ri-usecases/commits/gh-pages">
                      Commit History
                    </a>
                  </dd>
                
             
                
                  <dd>
                    <a href="https://twitter.com/respimg_commits">
                      Github commits on Twitter
                    </a>
                  </dd>
                
             
          
        
      
        
          <dt>Participate:</dt>
          
             
                
                  <dd>
                    <a href="http://w3c.responsiveimages.org">
                      Join the Responsive Images Community Group
                    </a>
                  </dd>
                
             
                
                  <dd>
                    <a href="http://list.responsiveimages.org">
                      Public mailing list
                    </a>
                  </dd>
                
             
                
                  <dd>
                    <a href="irc://irc.w3.org:6665/#respimg">
                      IRC: #respimg on <abbr title="World Wide Web Consortium">W3C</abbr>'s IRC
                    </a>
                  </dd>
                
             
                
                  <dd>
                    <a href="https://twitter.com/respimg">
                      Twitter
                    </a>
                  </dd>
                
             
                
                  <dd>
                    <a href="https://github.com/ResponsiveImagesCG/picture-element">
                      Github
                    </a>
                  </dd>
                
             
          
        
      
    
  </dl>
  
  
  
  
    
      <p class="copyright">
        <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> ©
        2013
        
        <a href="http://www.w3.org/"><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup>
        (<a href="http://www.csail.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>,
        <a href="http://www.ercim.eu/"><abbr title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>,
        <a href="http://www.keio.ac.jp/">Keio</a>, <a href="http://ev.buaa.edu.cn/">Beihang</a>), 
        
        All Rights Reserved.
        
        <abbr title="World Wide Web Consortium">W3C</abbr> <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
        <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and
        
          <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a>
        
        rules apply.
      </p>
    
  
  <hr>
</div>
    <p>
      <a href="http://responsiveimages.org"><img style="position: absolute; top: 1em; right: 1em;" src="images/RICG_logo_small.png" alt="Responsive Images Community Group"></a>
    </p>
    <section rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter" datatype="" property="dcterms:abstract" class="introductory" id="abstract"><h2 id="h2_abstract" role="heading" aria-level="1">Abstract</h2>
      <p>
        This document captures the use cases and requirements for standardizing
        a solution for responsive images. The <a class="internalDFN" href="#dfn-use-cases">use cases</a> and
        <a class="internalDFN" href="#dfn-requirements">requirements</a> were gathered with consultation with the <a href="http://w3c.org/">HTML Working Group</a> and <a href="http://whatwg.org">WHATWG</a> participants, <a href="http://www.w3.org/community/respimg/"><abbr title="Responsive Images Community Group">RICG</abbr></a> group members, and
        the general public.
      </p>
      <p id="welcome" class="now3c">
        Found a bug, typo, or issue? Please <a href="https://github.com/ResponsiveImagesCG/ri-usecases/issues?state=open">file
        a bug on github</a> or <a href="mailto:public-respimg@w3.org">email
        us</a>!
      </p>
    </section><section rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter" id="sotd" class="introductory"><h2 id="h2_sotd" role="heading" aria-level="1">Status of This Document</h2>
  
    
      
        <p>
          <em>This section describes the status of this document at the time of its publication. Other
          documents may supersede this document. A list of current <abbr title="World Wide Web Consortium">W3C</abbr> publications and the latest revision
          of this technical report can be found in the <a href="http://www.w3.org/TR/"><abbr title="World Wide Web Consortium">W3C</abbr> technical reports
          index</a> at http://www.w3.org/TR/.</em>
        </p>
        
        <p>
          This document was published by the <a href="http://www.w3.org/html/wg/">HTML Working Group</a> as a Working Group Note.
          
          
          If you wish to make comments regarding this document, please send them to 
          <a href="mailto:public-respimg@w3.org">public-respimg@w3.org</a> 
          (<a href="mailto:public-respimg-request@w3.org?subject=subscribe">subscribe</a>,
          <a href="http://lists.w3.org/Archives/Public/public-respimg/">archives</a>).
          
          
          
          
            All comments are welcome.</p>
          
        
          <p>
            Publication as a Working Group Note does not imply endorsement by the <abbr title="World Wide Web Consortium">W3C</abbr> Membership.
            This is a draft document and may be updated, replaced or obsoleted by other documents at 
            any time. It is inappropriate to cite this document as other than work in progress.
          </p>
        
        
        <p>
          
            This document was produced by a group operating under the 
             
                <a id="sotd_patent" about="" rel="w3p:patentRules" href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 <abbr title="World Wide Web Consortium">W3C</abbr> Patent Policy</a>.
            
          
          
          
            
              <abbr title="World Wide Web Consortium">W3C</abbr> maintains a <a href="http://www.w3.org/2004/01/pp-impl/40318/status" rel="disclosure">public list of any patent disclosures</a> 
            
            made in connection with the deliverables of the group; that page also includes instructions for 
            disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains
            <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential Claim(s)</a> must disclose the
            information in accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section
            6 of the <abbr title="World Wide Web Consortium">W3C</abbr> Patent Policy</a>.
          
          
        </p>
        
      
    
  
</section><section id="toc"><h2 id="h2_toc" role="heading" aria-level="1" class="introductory">Table of Contents</h2><ul id="respecContents" role="directory" class="toc"><li class="tocline"><a class="tocxref" href="#introduction"><span class="secno">1. </span>
        Introduction
      </a><ul class="toc"><li class="tocline"><a class="tocxref" href="#proposed-solutions"><span class="secno">1.1 </span>
          Proposed Solutions
        </a></li></ul></li><li class="tocline"><a class="tocxref" href="#limitations-of-current-techniques"><span class="secno">2. </span>
        Limitations of current techniques
      </a></li><li class="tocline"><a class="tocxref" href="#use-cases"><span class="secno">3. </span>
        Use cases
      </a><ul class="toc"><li class="tocline"><a class="tocxref" href="#resolution-based-selection"><span class="secno">3.1 </span>
          Resolution-based selection
        </a></li><li class="tocline"><a class="tocxref" href="#viewport-based-selection"><span class="secno">3.2 </span>
          Viewport-based selection
        </a></li><li class="tocline"><a class="tocxref" href="#device-pixel-ratio-based-selection"><span class="secno">3.3 </span>
          Device-pixel-ratio-based selection
        </a></li><li class="tocline"><a class="tocxref" href="#art-direction"><span class="secno">3.4 </span>
          <span>Art direction</span>
        </a></li><li class="tocline"><a class="tocxref" href="#design-breakpoints"><span class="secno">3.5 </span>
          Design breakpoints
        </a></li><li class="tocline"><a class="tocxref" href="#matching-media-features-and-media-types"><span class="secno">3.6 </span>
          Matching media features and media types
        </a></li><li class="tocline"><a class="tocxref" href="#relative-units"><span class="secno">3.7 </span>
          Relative units
        </a></li><li class="tocline"><a class="tocxref" href="#image-formats"><span class="secno">3.8 </span>
          Image formats
        </a></li><li class="tocline"><a class="tocxref" href="#user-control-over-sources"><span class="secno">3.9 </span>
          User control over sources
        </a></li></ul></li><li class="tocline"><a class="tocxref" href="#requirements"><span class="secno">4. </span>
        Requirements
      </a></li><li class="tocline"><a class="tocxref" href="#open-issues"><span class="secno">A. </span>
        Open issues
      </a></li><li class="tocline"><a class="tocxref" href="#acknowledgements-1"><span class="secno">B. </span>
        Acknowledgements
      </a></li></ul></section>
    
    <section id="introduction">
      <!--OddPage--><h2 id="h2_introduction" role="heading" aria-level="1"><span class="secno">1. </span>
        Introduction
      </h2>
      <p>
        In <a href="http://www.w3.org/TR/html5/">HTML</a>, a user agent's
        <dfn id="dfn-environmental-conditions">environmental conditions</dfn> are primarily expressed as CSS
        <dfn id="dfn-media-features">media features</dfn> (e.g., pixel-density, orientation, max-width,
        etc.) and CSS media types (e.g., print, screen, etc.). A
        <dfn id="dfn-responsive-image">responsive image</dfn> is an image that adapts in response to
        different <a class="internalDFN" href="#dfn-environmental-conditions">environmental conditions</a>: adaptations can include, but
        are not limited to, changing the dimensions, crop, or even the source
        of an image.
      </p>
      <p>
        Many <a href="http://www.w3.org/TR/css3-mediaqueries/#media1">media
        features</a> are dynamic in nature (e.g., a browser window is re-sized,
        a device is rotated from portrait to landscape, and so on), thus a user
        agent constantly responds to events that change the properties of media
        features. As a document's layout adapts to changes in media features
        and media type, an image's ability to communicate effectively can be
        significantly reduced (e.g., images start to show compression artifacts
        as they are scaled to match the quality of media or some media
        feature). When this happens, developers rely on various <a href="http://css-tricks.com/which-responsive-images-solution-should-you-use/">
        client/server-side solutions</a> to present images at different
        resolutions, or even in different formats. Swapping images provides a
        means to continue communicating effectively as the features of media
        change dynamically.
      </p>
      <p>
        Furthermore, as the <a href="https://github.com/ResponsiveImagesCG/picture-element/wiki/Display-technologies:-beyond-Retina">
        number and varieties of high-density screens has increased</a> (both on
        mobile and desktop devices), web developers have had to create custom
        techniques for serving images that best match a browser's
        <a class="internalDFN" href="#dfn-environmental-conditions">environmental conditions</a>. For a list of examples of the range of
        <dfn id="dfn-techniques">techniques</dfn> in use in 2012, see Chris Coyier's article
        "<a href="http://css-tricks.com/which-responsive-images-solution-should-you-use/">Which
        responsive images solution should you use?</a>". These techniques have
        a number of limitations, discussed below, which serve as the motivation
        to standardize a solution through the <a href="http://w3.org"><abbr title="World Wide Web Consortium">W3C</abbr></a>
        and <a href="http://whatwg.org">WHATWG</a>).
      </p>
      <p>
        In formulating the requirements, this document tries to be
        <em>neutral</em> - it is not predicated on any solution. The document
        only tries to describe the use cases and what the <a href="http://www.w3.org/community/respimg/"><abbr title="Responsive Images Community Group">RICG</abbr></a> understands, from
        <a href="https://github.com/ResponsiveImagesCG/picture-element/wiki/Relevant-resources#articles">
        practice</a>, would be needed to address the use cases in the form of
        <a class="internalDFN" href="#dfn-requirements">requirements</a>. The <a href="http://www.w3.org/community/respimg/"><abbr title="Responsive Images Community Group">RICG</abbr></a> expects that a
        technical specification can be created to formally address each of the
        <a class="internalDFN" href="#dfn-requirements">requirements</a> (i.e., the <dfn id="dfn-solution">solution</dfn>).
      </p>
      <section id="proposed-solutions">
        <h3 id="h3_proposed-solutions" role="heading" aria-level="2"><span class="secno">1.1 </span>
          Proposed Solutions
        </h3>
        <p>
          To date, four such specifications are currently under development,
          described below. The four proposed solutions are not mutually
          exclusive: together they address the set of <cite><a href="http://usecases.responsiveimages.org">Use Cases and Requirements for
          Responsive Images</a></cite>.
        </p>
        <dl>
          <dt>
            <cite><a href="http://dev.w3.org/html5/srcset/">The `srcset`
            attribute</a></cite>
          </dt>
          <dd>
            <p>
              Allows authors to define various image resources and “hints” that
              assist a user agent to determine the most appropriate image
              source to display. Given a set of image resources, the user agent
              has the option of either following or overriding the author’s
              declarations to optimize the user experience based on criteria
              such as display density, connection type, user preferences, and
              so on.
            </p>
          </dd>
          <dt>
            <cite><a href="http://picture.responsiveimages.org">The `picture`
            element</a></cite>
          </dt>
          <dd>
            <p>
              Building on <a href="http://dev.w3.org/html5/srcset/">srcset</a>,
              this specification defines a declarative solution for grouping
              multiple versions of an image based on different characteristics
              (e.g., format, resolution, orientation, etc.). This allows the
              user agent to select the optimum image to present to an end-user
              based on the user agent's <a class="internalDFN" href="#dfn-environmental-conditions">environmental conditions</a>, while
              also providing the ability to "<a class="internalDFN" href="#dfn-art-direction" title="art direction">art
              direct</a>" images.
            </p>
          </dd>
          <dt>
            <cite><a href="http://tools.ietf.org/html/draft-grigorik-http-client-hints">HTTP
            Client Hints</a></cite>
          </dt>
          <dd>
            <p>
              Defines a set of HTTP headers that allow browsers to indicate a
              list of device and agent specific preferences. Servers can then
              use these "client hints" to assist in content negotiation,
              ideally resulting in content being served that best matches the
              <a class="internalDFN" href="#dfn-environmental-conditions">environmental conditions</a> of the client for the resource
              being requested.
            </p>
          </dd>
          <dt>
            <cite><a href="http://tabatkins.github.io/specs/respimg/Overview.html">Proposal
            for RespImg Syntax</a></cite>
          </dt>
          <dd>
            <p>
              The <cite>RespImg Syntax</cite> introduces a new
              "<code>src-n</code>" attribute set on the <code>img</code>
              element that accepts a small set of microsyntaxes. These
              microsyntaxes address the viewport-based selection,
              device-pixel-ratio-based selection, and art direction use cases
              described in this document. The proposal claims to avoid the
              implementor concerns associated with the `picture` element
              proposal.
            </p>
          </dd>
        </dl>
      </section>
    </section>
    <section id="limitations-of-current-techniques">
      <!--OddPage--><h2 id="h2_limitations-of-current-techniques" role="heading" aria-level="1"><span class="secno">2. </span>
        Limitations of current techniques
      </h2>
      <p>
        As currently there are no standardized solutions implemented in
        mainstream browsers, web developers are relying on various <a href="http://css-tricks.com/which-responsive-images-solution-should-you-use/">
        techniques</a> to use responsive images in their applications.
        Unfortunately, there are significant <dfn id="dfn-limitations">limitations</dfn> with these
        <a href="http://css-tricks.com/which-responsive-images-solution-should-you-use/">
        techniques</a>:
      </p>
      <dl>
        <dt>
          Reliance on semantically neutral elements and CSS backgrounds:
        </dt>
        <dd>
          <p>
            Large images incur unnecessary download and processing time,
            slowing the experience for users. To work around this problem, web
            developers specify multiple sources of the same image at different
            resolutions and then pick the image of the correct size based on
            the viewport size. As web developers lack the markup to achieve
            what they need, they end up relying on semantically neutral
            elements, <a href="http://dev.w3.org/csswg/css-backgrounds/#background-image">CSS
            background images</a>, and JavaScript libraries. In other words,
            developers are being forced to willfully violate the authoring
            requirements of <a href="http://www.w3.org/TR/html5/">HTML</a>.
          </p>
        </dd>
        <dt>
          Bypass preload scanner
        </dt>
        <dd>
          <p>
            The reliance on semantically neutral elements (e.g., the
            <code>div</code> and <code>span</code> elements), instead of
            semantically meaningful elements such as <code>img</code>, prevents
            browsers from loading the image resources until after the DOM has
            (at least partially) loaded and scripts have run. This directly
            hinders the performance work browser engineers have done over the
            years to optimize resource loading (e.g., WebKit's <a href="https://github.com/WebKit/webkit/blob/master/Source/WebCore/html/parser/HTMLPreloadScanner.cpp">
            HTMLPreloadScanner</a>). Unnecessarily bypassing things like the
            preload scanner can have measurable performance impact when loading
            documents. See, for example, "<a href="http://gent.ilcore.com/2011/01/webkit-preloadscanner.html">The
            WebKit PreloadScanner</a>" by Tony Gentilcore for a small study
            that demonstrates an up to 20% impact in load time when WebKit's
            PreloadScanner is disabled. More recent <a href="https://plus.google.com/+IlyaGrigorik/posts/8AwRUE7wqAE">performance
            tests</a> yield similar results.
          </p>
        </dd>
        <dt>
          Reliance on scripts and server-side processing:
        </dt>
        <dd>
          <p>
            The <a href="http://css-tricks.com/which-responsive-images-solution-should-you-use/">
            techniques</a> rely on either JavaScript or a server-side solution
            (or both), which adds complexity and redundant HTTP requests to the
            development process. Furthermore, the script-based solutions are
            unavailable to users who have turned off JavaScript.
          </p>
        </dd>
      </dl>
      <p>
        The <abbr title="Responsive Images Community Group">RICG</abbr>
        believes standardization of a browser-based solution can overcome these
        <a class="internalDFN" href="#dfn-limitations">limitations</a>.
      </p>
    </section>
    <section id="use-cases">
      <!--OddPage--><h2 id="h2_use-cases" role="heading" aria-level="1"><span class="secno">3. </span>
        Use cases
      </h2>
      <p>
        The following <dfn id="dfn-use-cases">use cases</dfn> represent usage scenarios commonly
        seen "in the wild".
      </p>
      <section id="resolution-based-selection">
        <h3 id="h3_resolution-based-selection" role="heading" aria-level="2"><span class="secno">3.1 </span>
          Resolution-based selection
        </h3>
        <p>
          Developers generally want to provide the same image in multiple
          resolutions, so that high-res devices can get the optimum image for a
          given resolution, while low-resolution devices can avoid wasting time
          and bandwidth downloading overly-large files.
        </p>
        <figure id="fig-figure-shows-screens-that-having-different-resolutions.-these-resolutions-can-be-either-physical-matching-physical-pixels-or-virtual-matching-css-pixels-.x">
          <img src="images/resolution_selection.jpg" alt="Screens have a range of resolutions. Both real and virtual." style="max-width: 415px" class="stretchy">
          <figcaption>Fig. <span class="figno">1</span> <span class="fig-title">
            
              Figure shows screens that having different resolutions. These
              resolutions can be either physical (matching physical pixels) or
              virtual (matching css pixels).
            
          </span></figcaption>
        </figure>
      </section>
      <section id="viewport-based-selection">
        <h3 id="h3_viewport-based-selection" role="heading" aria-level="2"><span class="secno">3.2 </span>
          Viewport-based selection
        </h3>
        <p>
          Image dimensions in responsive layouts tend to vary according to the
          size of the viewport. This often results in images with large
          dimensions (e.g., 2x or more times the size of the viewport) being
          sent to browsers with narrow viewports, which are then resized by the
          browser to fit the design (see, for example, <cite><a href="http://blog.netvlies.nl/design-interactie/retina-revolution">Retina
          Revolution</a></cite> by Daan Jobsis and the <cite><a href="http://filamentgroup.com/lab/rwd_img_compression/">compressive
          images</a></cite> technique). Ideally, developers would like to serve
          images that match the user's viewport dimensions. Without a means to
          do this, they sometimes need to send more data to the user than they
          would otherwise need to.
        </p>
        <p>
          For example, a 1000px wide image might be appropriate as a 1x image
          when used to fill the background of the page, but it’s far too large
          to use for the same purpose on a 320px wide screen. On a screen that
          small, it’s more like a 2x or 3x image. In other words, the same
          image might be applicable to multiple viewport sizes, but at
          different effective resolutions.
        </p>
        <figure id="fig-to-avoid-sending-excess-data-developers-will-send-images-that-more-closely-match-the-size-of-the-viewport.x">
          <img src="images/viewport_selection.jpg" alt="3 different viewport layouts, where the size of images differs based on the viewport." class="stretchy" style="max-width: 415px">
          <figcaption>Fig. <span class="figno">2</span> <span class="fig-title">
            
              To avoid sending excess data, developers will send images that
              more closely match the size of the viewport.
            
          </span></figcaption>
        </figure>
      </section>
      <section id="device-pixel-ratio-based-selection">
        <h3 id="h3_device-pixel-ratio-based-selection" role="heading" aria-level="2"><span class="secno">3.3 </span>
          Device-pixel-ratio-based selection
        </h3>
        <p>
          To display images in a way that reduces perceptible artifacts (i.e.,
          so the images look "crisp"), devices with different screen densities
          require images with different minimal resolutions. Thus, the higher
          the pixel density, the more pixels an image needs to have to look
          good. This also applies to icons, where completely different images
          may need to be used for different device-pixel-ratios (see
          <cite><a href="http://mrgan.tumblr.com/post/708404794/ios-app-icon-sizes">All the
          sizes of iOS app icons</a></cite>, by Neven Mrgan).
        </p>
        <figure id="fig-on-a-device-with-a-device-pixel-ratio-greater-than-1-higher-image-resolutions-are-required-to-reduce-visual-artifacts-resulting-from-compression.x">
          <img src="images/dpr_selection.jpg" class="stretchy" style="max-width: 415px" alt="three devices, each having a unique device pixel ratio of 1x, 1.5, and 3x respectively.">
          <figcaption>Fig. <span class="figno">3</span> <span class="fig-title">
            
              On a device with a device-pixel-ratio greater than 1, higher
              image resolutions are required to reduce visual artifacts
              resulting from compression.
            
          </span></figcaption>
        </figure>
      </section>
      <section id="art-direction">
        <h3 id="h3_art-direction" role="heading" aria-level="2"><span class="secno">3.4 </span>
          <dfn id="dfn-art-direction">Art direction</dfn>
        </h3>
        <p>
          In a responsive design, it is typical to change an image so it can be
          targeted towards the features of a particular display (or set of
          displays). Sometimes this means cropping an image. Other times, it
          can mean a different image altogether that may have different
          proportions or may be changed in other ways to communicate more
          effectively in a layout. This means, for example:
        </p>
        <ul>
          <li>On a large screen, a large image with plenty of details can be
          shown (e.g., an object with a broad background).
          </li>
          <li>On a smaller screen, shrinking the same image can reduce its
          relevance, usefulness, and legibility. Thus, by "art directing", a
          web developer can better control communication by explicitly
          dictating which image should be shown at which size (or when some
          <a class="internalDFN" href="#dfn-environmental-conditions" title="environmental conditions">environmental condition</a> is
          met).
          </li>
        </ul>
        <p>
          This is illustrated in the figure below.
        </p>
        <figure id="fig-using-different-images-that-have-been-cropped-to-fit-a-particular-screen-s-features-can-help-in-communicating-a-message-effectively.x">
          <img src="images/art_direction.jpg" style="max-width:400px" class="stretchy" alt="four devices showing art directed crops of a dog.">
          <figcaption>Fig. <span class="figno">4</span> <span class="fig-title">
            
              Using different images that have been cropped to fit a particular
              screen's features can help in communicating a message
              effectively.
            
          </span></figcaption>
        </figure>
        <p>
          A related use case is when orientation determines:
        </p>
        <ul>
          <li>the source of the image,
          </li>
          <li>the crop,
          </li>
          <li>and how text flows around the image based on the size of the
          viewport.
          </li>
        </ul>
        <p>
          For example, on the Nokia Lumia site where it describes the <a href="http://browser.nokia.com/smartphones.html">Meego browser</a>, the
          Nokia Lumia is shown horizontally on wide screens. As the screen
          narrows, the Nokia Lumia is then shown vertically and cropped. Bryan
          and Stephanie Rieger, the designers of the site, explained that on a
          wide screen, showing the full phone horizontally showed the browser
          best; but on small screens, changing the image to vertical made more
          sense because it allowed the reader to still make out the features of
          the browser in the image.
        </p>
        <figure id="fig-video-showing-art-direction-used-on-nokia-s-meego-website.x">
          <video controls="" poster="videos/screenrmx1.jpg" class="stretchy" style="max-width: 652px" onclick="if(/Android/.test(navigator.userAgent))this.play();">
          <source src="videos/screenrmx1.m4v" type="video/mp4">
          <source src="videos/screenrmx1.webm" type="video/webm">
          <source src="videos/screenrmx1.ogv" type="video/ogg">
          <source src="videos/screenrmx1.mp4"><object type="application/x-shockwave-flash" data="videos/flashfox.swf" style="position:relative;" width="652" height="389">
            <param name="movie" value="videos/flashfox.swf">
            <param name="allowFullScreen" value="true">
            <param name="flashVars" value="autoplay=false&amp;controls=true&amp;fullScreenEnabled=true&amp;loop=false&amp;poster=videos/screenrmx1.jpg&amp;src=screenrmx1.m4v">
            <embed src="videos/flashfox.swf" style="position:relative;" flashvars="autoplay=false&amp;controls=true&amp;fullScreenEnabled=true&amp;loop=false&amp;poster=videos/screenrmx1.jpg&amp;src=screenrmx1.m4v" allowfullscreen="true" wmode="transparent" type="application/x-shockwave-flash" pluginspage="http://www.adobe.com/go/getflashplayer_en" width="652" height="389"> <img alt="Responsive images on Meego website" src="videos/screenrmx1.jpg" style="position:absolute;left:0;" title="Video playback is not supported by your browser" width="652" height="389">
          </object></video>
          <figcaption>Fig. <span class="figno">5</span> <span class="fig-title">
            
              Video showing art direction used on Nokia's Meego Website.
            
          </span></figcaption>
        </figure>
      </section>
      <section id="design-breakpoints">
        <h3 id="h3_design-breakpoints" role="heading" aria-level="2"><span class="secno">3.5 </span>
          Design breakpoints
        </h3>
        <p>
          In Web development, a <dfn id="dfn-breakpoint">breakpoint</dfn> is one of a series of
          <a href="http://www.w3.org/TR/css3-mediaqueries/">CSS Media
          Queries</a>, which can update the styles of a page based on matching
          of <a class="internalDFN" href="#dfn-media-features">media features</a>. A single breakpoint represents a rule (or
          set of rules) that determines the point at which the contents of that
          media query are applied to a page’s layout. For example:
        </p>
        <div class="example"><div class="example-title"><span>Example 1</span></div><pre class="example" style="overflow:auto">@media screen and (max-width: 16em) { ... }
@media screen and (max-width: 32em) { ... }
@media screen and (max-width: 41em) { ... }</pre></div>
        <p>
          Developers currently match specific <a class="internalDFN" href="#dfn-breakpoint" title="breakpoint">breakpoints</a> for images to the breakpoints that they
          have defined in the <a href="http://www.w3.org/Style/CSS/Overview.en.html">CSS</a> for their
          applications. Being able to match the breakpoints ensures that images
          are operating under the same rules that define the layout of a
          design. It also helps developers verify their approach by ensuring
          that the same viewport measurement tests are being used in both
          <a href="http://www.w3.org/TR/html5/">HTML</a> and <a href="http://www.w3.org/Style/CSS/Overview.en.html">CSS</a>. If the
          developer cannot specify breakpoints for images in the same manner
          that they are defined for the design, developers will need to convert
          the breakpoints back to the values specified in the layout in order
          to verify that they match. This increases authoring time and the
          likelihood of human-error on the part of developers.
        </p>
        <p>
          For example, if a <a class="internalDFN" href="#dfn-breakpoint">breakpoint</a> is specified as "<code>max-width:
          41em</code>", then web developers would like to define a similar
          breakpoint for images at a <code>max-width</code> of
          <code>41em</code>. Otherwise they are forced to transform
          measurements into another unit, like pixels, which is tedious and
          potentially error-prone.
        </p>
      </section>
      <section id="matching-media-features-and-media-types">
        <h3 id="h3_matching-media-features-and-media-types" role="heading" aria-level="2"><span class="secno">3.6 </span>
          Matching media features and media types
        </h3>
        <p>
          According to <cite>Wikipedia's</cite> article on "<a href="http://en.wikipedia.org/wiki/Dots_per_inch">dots per inch</a>":
        </p>
        <blockquote>
          <p>
            "An&nbsp;inkjet printer&nbsp;… is typically capable of 300-600 DPI.
            A&nbsp;laser printer&nbsp;… [prints] in the range of 600 to
            1,800&nbsp;DPI."
          </p>
        </blockquote>
        <p>
          As printers generally have the ability to pack more points per inch
          than a device's screen, printers have to compensate for the lack of
          pixel data by applying&nbsp;<a href="http://en.wikipedia.org/wiki/Reprographic" title="Reprographic">reprographic</a>&nbsp;techniques, such as <a href="http://en.wikipedia.org/wiki/Halftone">half toning</a>, to
          simulate&nbsp;<a href="http://en.wikipedia.org/wiki/Continuous_tone" title="Continuous tone">continuous tone</a>&nbsp;in imagery. As
          illustrated below, applying such techniques can cause images to look
          blurry and low-quality when compared to text.
        </p>
        <figure id="fig-example-of-a-48px-by-48px-image-and-text-printed-at-1-200-dpi.-because-of-the-lack-of-image-data-the-printer-compensates-by-using-the-halftone-reprographic-technique.-note-that-the-text-stays-crisp-and-is-printed-at-the-full-1-200-dpi.x">
          <img src="images/printed_image.jpg" class="stretchy" style="max-width:403px" alt="image comparison between screen and print.">
          <figcaption>Fig. <span class="figno">6</span> <span class="fig-title">
            
              Example of a 48px by 48px image and text printed at 1,200 DPI.
              Because of the lack of image data, the printer compensates by
              using the halftone reprographic technique. Note that the text
              stays crisp and is printed at the full 1,200 DPI.
            
          </span></figcaption>
        </figure>
        <p>
          Allowing developers to reference images at different resolutions
          could allow user agents to choose an image that best matches the
          capabilities of the printer. For example, a photo sharing site could
          provide a bandwidth-optimized image for display on screen, but a
          high-resolution image for print. The same technique could also be
          used for e-book formats, such as <a href="http://idpf.org/epub">EPUB</a>.
        </p>
        <p>
          However, displaying a color image on monochrome media (e.g., paper
          and e-ink displays) can be problematic: different colors with similar
          luminosity are impossible to distinguish on monochrome media. This
          problem is illustrated in the figure below, where it becomes nearly
          impossible to associate slices of a pie chart with corresponding
          labels.
        </p>
        <figure id="fig-two-pie-charts-one-in-color-and-one-in-black-and-white-which-demonstrate-the-problem-with-switching-from-color-to-monochrome-media.-in-the-black-and-white-graph-it-is-extremely-difficult-to-know-which-slice-relates-to-which-label-except-in-the-case-of-commute-which-is-a-lighter-shade-.x">
          <img class="stretchy" src="images/color_and_bw_graph.png" style="max-width: 560px" alt="a color and a black and white graph">
          <figcaption>Fig. <span class="figno">7</span> <span class="fig-title">
            
              Two pie charts, one in color and one in black and white, which
              demonstrate the problem with switching from color to monochrome
              media. In the black and white graph, it is extremely difficult to
              know which slice relates to which label (except in the case of
              "commute", which is a lighter shade).
            
          </span></figcaption>
        </figure>
        <p>
          Currently, server-side solutions exist to adapt web content to e-ink
          displays (e.g., <a href="http://kinstant.com/">kinstant</a>), but
          such services only work on text and layout and not on images. As
          interpreting the meaning of images is a problem of <a href="http://en.wikipedia.org/wiki/Semiotics">semiotics</a>, it is
          infeasible that this problem can ever be computationally solved. The
          only feasible solution is for authors to provide alternative image
          content that communicates effectively in monochrome media.
        </p>
        <p>
          Lastly, through the <a href="http://www.w3.org/TR/css3-mediaqueries/">CSS Media Queries
          specifications</a>, the <a href="http://www.w3.org/Style/CSS/">CSS
          Working Group</a> continues to add media features to the Web
          platform. New media features in <a href="http://dev.w3.org/csswg/mediaqueries4/">CSS Media Queries level
          4</a> include <a href="http://dev.w3.org/csswg/mediaqueries4/#script">script</a>, <a href="http://dev.w3.org/csswg/mediaqueries4/#pointer">pointer</a>,
          <a href="http://dev.w3.org/csswg/mediaqueries4/#hover">hover</a>, and
          <a href="http://dev.w3.org/csswg/mediaqueries4/#luminosity">luminosity</a>.
          The lack of a declarative mechanism to associate image content with
          media features means that developers cannot use them without relying
          on the aforementioned <a class="internalDFN" href="#dfn-limitations" title="limitations">limited</a>
          <a class="internalDFN" href="#dfn-techniques">techniques</a>.
        </p>
      </section>
      <section id="relative-units">
        <h3 id="h3_relative-units" role="heading" aria-level="2"><span class="secno">3.7 </span>
          Relative units
        </h3>
        <p>
          A common practice in creating flexible layouts is to specify the size
          values in media queries as relative units (e.g., <code>em</code>s or
          percentages). This approach allows layouts to match the users’
          default font size (based on zoom level), and it avoid cases where the
          layout breaks on devices who set a default font-size is set to
          something other than the usual 16px.
        </p>
        <p>
          If art-directed images are not specified in relative units, they can
          either break the layout or become distorted when faced with a
          uncommon default font-size (e.g., Amazon's Kindle defaults to 20px
          instead of the usual 16px).
        </p>
      </section>
      <section id="image-formats">
        <h3 id="h3_image-formats" role="heading" aria-level="2"><span class="secno">3.8 </span>
          Image formats
        </h3>
        <p>
          Developers rely on the different capabilities of a range of image
          formats to communicate effectively. These capabilities include, but
          are not limited to, alpha transparency, animation, high-color depth
          support, or better compression ratios for certain image categories.
          For example, JPEG offers developers good optimization between image
          quality and file size, but lacks alpha transparency or animation. So,
          in cases where alpha transparency or animation is needed, developers
          may instead rely on PNG, GIF, and emerging formats like WebP.
        </p>
        <p>
          In a responsive design, images need to be displayed at different
          sizes and device pixel ratios. When possible, a vector format such as
          SVG might be most appropriate. There have also been proposals for new
          responsive image formats (see, for example, <a href="http://www.netmagazine.com/opinions/need-responsive-image-format">Christopher
          Schmitt's .net article</a>).
        </p>
        <p>
          Although a web developer may want to use a specific image format, new
          or otherwise, the browser may not always support it. Currently,
          developers are forced to abandon the most suitable image format in
          favor of one that has ubiquitous support across user agents.
        </p>
      </section>
      <section id="user-control-over-sources">
        <h3 id="h3_user-control-over-sources" role="heading" aria-level="2"><span class="secno">3.9 </span>
          User control over sources
        </h3>
        <p>
          In situations where the user knows their bandwidth is limited or
          expensive (e.g., while roaming), the browser could assist users by:
        </p>
        <ul>
          <li>Giving users an option to only download images in the quality
          they desire - or disable images all together.
          </li>
          <li>Automatically select the most suitable image for the browsing
          environment.
          </li>
        </ul>
        <p>
          There are browsers already catering for these kinds of situations.
          For example, Opera Mini provides users with a choice of image quality
          (but those images are compressed on the server). Amazon's Silk
          browser also compresses images "in the cloud" (i.e., through their
          own proxy servers) before serving those images to a user's device.
          Google Chrome also allows users to disable images altogether through
          "site preferences".
        </p>
      </section>
    </section>
    <section id="requirements">
      <!--OddPage--><h2 id="h2_requirements" role="heading" aria-level="1"><span class="secno">4. </span>
        Requirements
      </h2>
      <p>
        The <a class="internalDFN" href="#dfn-use-cases">use cases</a> give rise to the following
        <dfn id="dfn-requirements">requirements</dfn>:
      </p>
      <ol>
        <li>
          <p>
            To allow for art direction, the <a class="internalDFN" href="#dfn-solution">solution</a> <em title="MUST" class="rfc2119">MUST</em> afford
            developers the ability to match image sources with particular media
            features and/or media types - and the user agent <em title="SHOULD" class="rfc2119">SHOULD</em> update the
            source of an image as the media features and media types of the
            browser environment change dynamically.
          </p>
        </li>
        <li>
          <p>
            The <a class="internalDFN" href="#dfn-solution">solution</a> <em title="MUST" class="rfc2119">MUST</em> support selection based on viewport
            dimensions, screen resolution, and device-pixel-ratio (DPR).
            Sending the right image for the given dimension and DPR avoids
            delaying the page load, wasting bandwidth, and potentially reduces
            the impact on battery life (as the device's antenna can be powered
            off more quickly and smaller images are faster to process and
            display). It can also potentially save users money by not
            downloading redundant image data.
          </p>
        </li>
        <li>
          <p>
            The <a class="internalDFN" href="#dfn-solution">solution</a> <em title="MUST" class="rfc2119">MUST</em> degrade gracefully on legacy user agents
            by, for example, relying on HTML's built-in fallback mechanisms and
            legacy elements.
          </p>
        </li>
        <li>
          <p>
            The <a class="internalDFN" href="#dfn-solution">solution</a> <em title="MUST" class="rfc2119">MUST</em> afford developers with the ability to
            include content that is accessible to assistive technologies.
          </p>
        </li>
        <li>
          <p>
            The <a class="internalDFN" href="#dfn-solution">solution</a> <em title="MUST NOT" class="rfc2119">MUST NOT</em> require server-side processing to
            work. However, if required, server-side adaptation can still occur
            through <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html">content
            negotiation</a> or similar techniques (i.e., they are not mutually
            exclusive).
          </p>
        </li>
        <li>
          <p>
            The <a class="internalDFN" href="#dfn-solution">solution</a> <em title="MUST" class="rfc2119">MUST</em> afford developers the ability to define
            the breakpoints for images as either minimum values (mobile first)
            or maximum values (desktop first) to match the media queries used
            in their design.
          </p>
        </li>
        <li>
          <p>
            The <a class="internalDFN" href="#dfn-solution">solution</a> <em title="SHOULD" class="rfc2119">SHOULD</em> allow developers to specify images in
            different formats (or specify the format of a set of image
            sources).
          </p>
        </li>
        <li>
          <p>
            To provide compatibility with legacy user agents, it <em title="SHOULD" class="rfc2119">SHOULD</em> be
            possible for developers to <a href="http://remysharp.com/2010/10/08/what-is-a-polyfill/">polyfill</a>
            the <a class="internalDFN" href="#dfn-solution">solution</a>. See the <a href="https://github.com/w3ctag/extending-html-responsibly/blob/master/RICG-recs/ricg.md">
            <abbr title="World Wide Web Consortium">W3C</abbr>'s TAG's recommendations to the <abbr title="Responsive Images Community Group">RICG</abbr>.</a>
          </p>
        </li>
        <li>
          <p>
            The <a class="internalDFN" href="#dfn-solution">solution</a> <em title="SHOULD" class="rfc2119">SHOULD</em> afford user agents with the ability to
            provide a user-settable preference for controlling which source of
            an image they prefer.&nbsp;For example, &nbsp;preference options
            could include: "always lowest resolution", "always high
            resolution", "download high resolution as bandwidth permits", and
            so on. To be clear, user agents are not required to provide such a
            user-settable preference, but the <a class="internalDFN" href="#dfn-solution">solution</a> needs to be
            designed in such a way that it could be done.
          </p>
        </li>
        <li>
          <p>
            In order to avoid introducing delays to the page load, the solution
            <em title="MUST" class="rfc2119">MUST</em> integrate well with existing performance optimization provided
            by browsers (e.g., the solution would work well with a browser's
            the preload scanner). Specifically, the solution needs to result in
            faster page loads than the current <a href="http://css-tricks.com/which-responsive-images-solution-should-you-use/">
            techniques</a> are providing.
          </p>
        </li>
      </ol>
    </section>
    <section id="open-issues" class="appendix">
      <!--OddPage--><h2 id="h2_open-issues" role="heading" aria-level="1"><span class="secno">A. </span>
        Open issues
      </h2>
      <p>
        We are tracking <dfn id="dfn-open-issues">open issues</dfn> on Github. <a href="https://github.com/ResponsiveImagesCG/ri-usecases/issues">Please help
        us close them</a>!
      </p>
      <h2 id="changes-history">
        Changes history
      </h2>
      <p>
        A <a href="https://github.com/ResponsiveImagesCG/ri-usecases/commits/gh-pages">complete
        history of changes</a> is available on Github.
      </p>
      <p>
        You can also see <a href="https://github.com/ResponsiveImagesCG/ri-usecases/issues?state=closed">
        all the closed issues</a> relating to this document.
      </p>
    </section>
    <section id="acknowledgements-1" rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter" class="appendix">
      <!--OddPage--><h2 role="heading" aria-level="1" id="acknowledgements"><span class="secno">B. </span>
        Acknowledgements
      </h2>
      <p>
        This document is composed of contributions from participants of the
        responsive images community group.
      </p>
      <p>
        The editors would like to thank the following people for reviewing this
        document: Mike Taylor, Doug Shults, Barbara Barbosa Neves, Eileen Webb,
        and Anselm Hannemann.
      </p>
      <p>
        This document repoduces text from <a href="http://www.xanthir.com/contact/">Tab Atkin</a>'s <cite>Proposal for
        RespImg Syntax</cite>, as permitted by its C0 license.
      </p>
      <p>
        The figure in the viewport-based selection section is a derivative work
        from <cite><a href="http://24ways.org/2012/responsive-images-what-we-thought-we-needed/" rel="bookmark">Responsive Images: What We Thought We Needed</a></cite>,
        by <a href="http://paulrobertlloyd.com/">Paul Robert Lloyd</a>.
      </p>
      <p id="participantslist">
        <!--
        To get the participant's list, go to
        http://www.w3.org/community/respimg/participants

        var all = document.querySelectorAll("td>h3"),
            each = [];
        for(var i = 0; i < all.length; i++){
                each.push(all.item(i).textContent);
        }
        console.log(each.join(", "))
        -->
         <dfn id="dfn-participants">Participants</dfn> of the <a href="http://w3c.responsiveimages.org">Responsive Images Community Group</a>
        at the time of publication were: Barry Atimer, Daniel Abril, George
        Adamson, Heide Alexander, Marie Alhomme, John Allan, Joshua Allen,
        Angely Alvarez, Agustin Amenabar, Aaryn Anderson, Philip Andrews,
        Ritchie Anesco, Phil Archer, Tony Atayi, Tom Atkins, Justin Avery,
        Mohsen Azimi, Phillip Baker, Raymond Baker, Michael Balensiefer, Toni
        Barrett, Bruno Barros, Paul Barton, Adrian Bateman, Jesse Renée Beach,
        Robin Berjon, Seth Bertalotto, Anirban Bhattacharya, Nicolaas Bijvoet,
        Barna Bitai, Nathan Bleigh, Andreas Bovens, J. Albert Bowden, Adam
        Bradley, Rodrigo Brancher, Gordon Brander, Paul Bridgestock, Aaron
        Brosey, Brandon Brown, Cory Brown, mairead buchan, Kris Bulman, Ariel
        Burone, Mathias Bynens, Marcos Caceres, Rusty Calder, Ben Callahan,
        Loïc Calvy, Welch Canavan, Chuck Carpenter, Brandon Carroll, Frederico
        Cerdeira, Daniel Chamberlin, Adi Chikara, David Clements, Geri Coady,
        Anne-Gaelle Colom, Cyril Concolato, Jessica Constantine, Greg Cota,
        Geoff Cowan, Andy Crum, David D'Amico, Jason Daihl, Francois Daoust,
        Kevin Davies, Robert Dawson, Jacques de Klerk, Timothy de Paris, Ryan
        DeBeasi, Anna Debenham, Darryl deHaan, David Demaree, George DeMet, Ian
        Devlin, Alex DiLiberto, peter droogmans, Ronni Dyrholm Chidekel,
        simpson eddie, Sylvia Egger, Dominic Fee, Ève Février, Maximiliano
        Firtman, Ben Fonarov, Harry Fozzard, Marlene Frykman, Dennis Gaebel,
        Igor Gajosinskas, Nicolas Gallagher, Miguel Garcia, Rafael Garcia
        Lepper, Larry Garfield, Peter Gasston, George GeorgeHaeger, David Goss,
        Chris Grant, Petra Gregorova, Ilya Grigorik, Jason Grigsby, Aaron
        Grogg, Antoine Guergnon, Jeff Guntle, Aaron Gustafson, Jason Haag,
        Jordan Haines, Cristina Hanes, Patrick Haney, Anselm Hannemann, chris
        hardy, Vincent Hardy, Bridget Harrison, Duncan Hawthorne, Dominique
        Hazaël-Massieux, Chris Hilditch, Jon Hill, Nathan Hinshaw, Sean Hintz,
        John Holt Ripley, Enrico Hösel, Peter Hrynkow, Kym Huang, Shane Hudson,
        Vinicius Ianni, Tomomi Imura, Philip Ingrey, Bryn Jackson, Rihnna
        Jakosalem, Brett Jankord, Scott Jehl, Dave Johnson, Nathanael Jones,
        Danny Jongerius, Michael Jovel, Chao Ju, Tim Kadlec, Raj Kaimal, Kevin
        Joe Kanger, Frédéric Kayser, Serge K. Keller, Arthur Khachatryan, Jin
        Kim, Andreas Klein, Peter Klein, John Kleinschmidt, Daniel Konopacki,
        Darius Kruythoff, Zoran Kurtin, Vitaliy Kuzmin, Gerardo Lagger, Adam
        Lake, Chris Lamothe, Tom Lane, Matthieu Larcher, Christopher Latham,
        Bruce Lawson, Zach Leatherman, Silas Lepcha, Kornel Lesinski, Chris
        Lilley, grappler login, william lombardo, Tania Lopes, Amie Lucas,
        André Luís, Jacine Luisi, David Maciejewski, Kevin Mack, Ethan Malasky,
        Josh Marinacci, Eduardo Marques, Mathew Marquis, Daniel Martínez, Tom
        Maslen, Jacob Mather, Chris McAndrew, Mark McDonnell, Andre Jay
        Meissner, Benjamin Melançon, Julian Mendl, Rick Messer, Zane Milakovic,
        Denys Mishunov, Sabine Moebs, Ian Moffitt, Orestis Molopodis, jason
        morita, David Moulton, Bobby Mozumder, Brian Muenzenmeyer, Emi Myoudou,
        Irakli Nadareishvili, Giorgio Natili, Jonathan Neal, Christian
        Neuberger Jr, David Newton, Todd Nienkerk, Ashley Nolan, Johnna Nonboe,
        Kenneth Nordahl, Mark Nottingham, Lewis Nyman, Darrel O'Pry, Alejandro
        Oviedo, David Owens, Paddy O’Hanlon, Isabel Palomar, suzanne peter,
        Hassadee Pimsuwan, Guy Podjarny, Andreas Pollak, gentian polovina, Dave
        Poole, Florent Preynat, Manik Rathee, François REMY, Venkatesh
        Rengasamy, Jen Reynolds, Ricardo Andrade Belo Ricardo Belo, Michael
        Riethmuller, Carlo Rizzante, John Rodler, César Rodríguez, Nestor
        Rojas, Adrian Roselli, David Rupert, Chris Ruppel, Oguzcan Sahin,
        Viljami Salminen, Luca Salvini, Ana Sampaio, Luke Sands, crazyrohila
        sanjay, aron santa, Osny Santos, Jad Sarout, Brandon Satrom, Jeroen
        Savat, Stéphane Savona, Christoph Saxe, Doug Schepers, Jason Schmidt,
        Christopher Schmitt, Joe Schmitt, Greg Schumacher, Boaz Sender, SHAHINA
        SHEIK, Tomoyuki Shimizu, Ariel Shkedi, Abdul Wahid Sial, Pandapotan
        Silaban, Mauricio Silva Teixeira de Nobrega, Jen Simmons, Michael
        Singleterry, Katerina Skotalova, David Sleight, Michael[tm] Smith, Nick
        Snyder, Ignacio Soriano Cano, Steve Souders, Brenden Sparks, Aaron
        Staker, Aaron Stanush, Walter Stevenson, Bridget Stewart, Jared
        Stilwell, Matt Stow, Shari Sullivan, Kevin Suttle, Patrick Szalapski,
        Satoru Takagi, Rob Tarr, Philipp Tautz, Nguyen Thao Thao, Edward
        Thurgood, Anthony Ticknor, Erek Tinker, Sebastián Tromer, Tsvetan
        Tsvetkov, Yusuke Uchida, Mads Ulsø Østergaard, Katarina Ur, Adam van
        den Hoven, Jacob van Zijp, Lucas Vilaboim, Jitendra Vyas, Amy W, Tady
        Walsh, Yoav Weiss, George White, Michael Whittet, Matt Wilcox, Richard
        Wild, John Albin Wilkins, Chris Williams, Rory Wilson, Owen Winkler,
        Robin Winslow, Cyril Wolfangel, Mike Woodard, Jeremy Worboys, Mike Wu,
        Bruce Zawalsky, Carlos Zepeda, and jintian zheng.
      </p>
      <p id="participants">
        A <a href="http://www.w3.org/community/respimg/participants">complete
        list of participants</a> of the Responsive Images Community Group is
        available at the <abbr title="World Wide Web Consortium">W3C</abbr> Community Group Website.
      </p>
    </section>
  

</body></html>