--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/responsive-images/use-cases.html Wed Oct 17 15:48:00 2012 -0400
@@ -0,0 +1,259 @@
+<!DOCTYPE html>
+<html>
+<head>
+<title>Use Cases and Requirements for Standardizing Responsive Images</title>
+<meta http-equiv='Content-Type' content='text/html;charset=utf-8'/>
+<script src='http://www.w3.org/Tools/respec/respec-w3c-common' class='remove' async></script>
+<script type="text/javascript" class='remove'>
+ var respecConfig = {
+ specStatus: "unofficial",
+ shortName: "respimg",
+ noIDLSorting: true,
+ edDraftURI: "http://picture.responsiveimages.org",
+
+ editors: [
+ {
+ name: "Marcos Cáceres",
+ company: "Responsive Images Community Group",
+ companyURL: "http://www.w3.org/community/respimg/"
+ },
+ {
+ name: "Mat Marquis",
+ company: "Responsive Images Community Group",
+ companyURL: "http://www.w3.org/community/respimg/"
+ },
+ {
+ name: "Yoav Weiss",
+ company: "Responsive Images Community Group",
+ companyURL: "http://www.w3.org/community/respimg/"
+
+ },
+ {
+ name: "Adrian Bateman",
+ company: "Microsoft Corporation",
+ companyURL: "http://www.microsoft.com/"
+ }],
+ wg: "Responsive Images Community Group",
+ wgURI: "http://www.w3.org/community/respimg/",
+ wgPublicList: "public-respimg",
+ wgPatentURI: "http://www.w3.org/2004/01/pp-impl/40318/status",
+ issueBase: "https://github.com/ResponsiveImagesCG/ri-usecases/issues",
+ noIDLSectionTitle: true
+ };
+ </script>
+<style type="text/css">
+.informative {
+ background-color: rgb(233, 251, 233);
+}
+ol > li {
+ margin-bottom: 1em;
+}
+#conformance dd {
+ margin-bottom: 1em;
+}
+pre {
+ tab-size: 3; /* Reduce indentation. */
+}
+.informative-subhed {
+ font-size: 120%;
+}
+a {
+ color: blue
+}
+a:not([href]) {
+ color: red
+}
+#open-issues-xhr {
+ font-size: .9em;
+}
+#open-issues-xhr li {
+ padding: .25em 0;
+}
+#open-issues-xhr .meta {
+ display: block;
+ font: normal .8em/1 sans-serif;
+ padding: .35em 0 0 0;
+}
+#open-issues-xhr .meta b {
+ font-weight: normal;
+}
+#open-issues-xhr .meta span {
+ display: block;
+ float: left;
+ width: 5.5em;
+}
+</style>
+</head>
+<body>
+
+<section id='abstract'>
+ <p>This document captures the use cases and requirements for standardizing a solution for responsive images.</p>
+
+ <p style="text-align: center; font-size: 1.5em; border: .2em dotted black; background-color: #E6E6E6; padding: 1em">Hi! If you find any bugs, typos, or issues please <a href=" https://github.com/ResponsiveImagesCG/ri-usecases/issues">file a bug on github</a> or <a href="mailto:public-respimg@w3.org">email us</a>! </p>
+</section>
+
+<section id="introduction">
+ <h1>Introduction</h1>
+ <p>To visually communicate effectively, developers require a means to explicitly control which image, from a set of images, is shown to a user in response to the <dfn>environmental conditions</dfn> of the user agent. In a [[HTML5]] user agent, environmental conditions are expressed as CSS media features (e.g., max-width, orientation, monochrome, etc.) and CSS media types (e.g., print, screen, etc.). Many media features 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 cause the properties of media features to change. These changes in media features and media type can reduce an image's ability to communicate effectively (e.g. images become blurry or pixelated).</p>
+ <p>As the number and varieties of high-density screens has increased (both on mobile and desktop devices), web developers have created custom techniques for serving images that best match a user's browsing environment. For a list of examples of the range of techniques 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>". However, these techniques have a number of shortcomings, which are discussed below (and these shortcomings serve as the motivation to reach out to the <a href="http://w3.org">W3C</a> and <a href="http://whatwg.org">WHATWG</a> for standardization). </p>
+</section>
+
+<section id="sotd">
+ <p>The <a href="http://www.w3.org/community/respimg/">RICG</a>'s goal for this document is to capture a complete set of developer requirements for responsive images. The group intends to deliver the document to the HTMLWG and <a href="http://whatwg.org">WHATWG</a> for comment (see <a href="https://www.w3.org/Bugs/Public/show_bug.cgi?id=17061">bug 17061</a>). The use cases and requirements were gathered by consultation with <a href="http://w3c.org/">W3C</a> and <a href="http://whatwg.org">WHATWG</a> participants, community group members, and the general public. The RICG's goal for this document is to make sure that developer's requirements for responsive images have been formally captured. </p>
+ <p>The RICG expects that a technical specification can be created to formally address each of the <a>requirements</a> (i.e., the <dfn>solution</dfn>). To date, two such specifications are currently under development: </p>
+ <ul>
+ <li><cite><a href="http://dvcs.w3.org/hg/html-proposals/raw-file/tip/responsive-images/responsive-images.html">The picture element: An HTML extension for responsive images</a></cite>. </li>
+ <li><cite><a href="http://dev.w3.org/html5/srcset/">The srcset attribute: An HTML extension for adaptive images</a></cite>.</li>
+ </ul>
+ <p>Proposed solutions are not mutually exclusive. They may work together to address the complete set of <a>use cases</a> and <a>requirements</a>.</p>
+</section>
+<section id="problems">
+ <h1>Problems with current techniques</h1>
+ <p>There are a number of problems with the <a href="http://css-tricks.com/which-responsive-images-solution-should-you-use/">techniques</a> currently being relied on by web developers: </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 solve this problem, web developers provide multiple sources of the same image at different resolutions and then pick the correct size image based on the viewport size. This is commonly done for CSS background images in responsive designs, but web developers lack the markup to do so for images in HTML without hacking together a solution. This means that developers have resorted to using <code>div</code> and other container elements to achieve the desired functionality. </p>
+ <p>In other words, developers are being forced to work around, or completely ignore, authoring requirements of [[!HTML5]].</p>
+ </dd>
+ <dt>Reliance on scripts and server side processing: </dt>
+ <dd>
+ <p>Current solutions to this "responsive images" problem rely on either JavaScript libraries or server-side solutions - both of which add unnecessary complexity to the development process. </p>
+ </dd>
+ </dl>
+ <p>The RICG believes that standardization of a browser-based solution can overcome these problems. </p>
+</section>
+
+<section id="usecases">
+ <h1>Use cases</h1>
+
+ <p>The following <dfn>use cases</dfn> provide represent the techniques currently used by Web developers to achieve both repulsive designs with responsive images. </p>
+ <section>
+ <h2>Art direction</h2>
+ <p> To communicate effectively across the range of screen resolutions and device pixel ratios available on devices today, web developers often need to provide different versions of the same image. Developers do this because if an image is too small on a screen the meaning of that image cannot be properly communicated to a user - conversely, if more space is available, a developer may want to show a different image that depicts more information. Another reason developers do this is to avoid images becoming blurry when scaled too much by the browser.</p>
+ <p>For example, in the following figure it is difficult to discern the man's facial expressions on the image on the left when compared to the image on the middle. The image on the far right show the effects of scaling the image too much, which also affects the image's ability to communicate effectively:</p>
+<figure>
+<img src="images/obama_small.jpg" alt="Obama talking seriously on the phone" width="240" height="160">
+<img src="images/obama_crop.png" alt="Obama talking seriously on the phone" width="240" height="160">
+<img src="images/obama_scaled.png" alt="Obama talking seriously on the phone" width="240" height="161">
+<figcaption>Three images showing how The figure shows how different zooms and crop convey information about a man talking on the phone.</figcaption>
+</figure>
+ <p>Typically, the desired communicative effect is achieved by changing the crop of an image so it can be targetted at the features of a particular display (or set of displays):</p>
+ <ul>
+ <li>a website wants to normally show a large image (e.g. of a figure with a broad background) on displays that are big enough.</li>
+ <li>when shown on a smaller screen, simply shrinking the image may reduce its relevance, usefulness, or legibility, and thus the site may wish to show a different cropping or layout of the same image at the smaller size.</li>
+ </ul>
+ <p>This is illustrated in the figure below. </p>
+ <figure>
+ <img src="http://cdn.css-tricks.com/wp-content/uploads/2012/05/difimages.jpg">
+ <figcaption>Using different images that have been cropped to fit a particular screen's features can help in communicating a message effectively. </figcaption>
+ </figure>
+<p>Another related use case is one where orientation determines the source of the image, the crop, and how text flows around an image based on the size of the viewport. For example, on the Nokia Browser site where it describes the <a href="http://browser.nokia.com/smartphones.html">Meego browser</a>, the Nokia Lumia is shown <a href="http://browser.nokia.com/resources/images/home-feature.png">horizontally on wide screens</a>. As the screen narrows, the Nokia Lumia is then shown <a href="http://browser.nokia.com/resources/images/smartphones/choose-meego@320.png">vertically and cropped</a>. Bryan and Stephanie Rieger, the designers of the site, have talked about how 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>
+</section>
+
+ <section>
+ <h2>Design breakpoints</h2>
+ <p>In Web development, a <dfn>breakpoint</dfn> is one of a series of <a href="http://www.w3.org/TR/css3-mediaqueries/">CSS Media Queries</a> that update the styles of a page based on matching some media features. A single breakpoint represents a logical rule (or set of rules) determining the point at which the contents of a media query are applied to a page’s layout.</p>
+ <p>Developers currently match specific <a>breakpoints</a> for images to the breakpoints that they have defined in the CSS of their responsive designs. 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 HTML and CSS.</p>
+ <p> If a breakpoint in the design is specified in [[CSS21]] as:</p>
+ <pre class="example"><code>@media screen and (max-width: 41em) {}</code></pre>
+ <p>Then web developers would like to be able to define a similar breakpoint for images at a max-width of 41em and not have to translate that measurement into another unit like pixels even if it is possible to calculate that measurement:</p>
+ <ul>
+ <li>The default font size in most browsers is 16 pixels. So 41em can be calculated to be 41 * 16 = 656 pixels. Calculating this for every breakpoint, while possible, would be tedious and potentially error-prone for developers.</li>
+ <li>Unless the image break points support both max and min values, then the image breakpoint will need to be further modified from the layout breakpoint that it was derived from. For example, if the image format only supports minimum width tests, then instead of using a maximum width of 656 pixels, the document developer would need to specify 657 pixels as a minimum width for the breakpoint.</li>
+ </ul>
+ <p>When debugging a document, 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 errors on the part of developers.</p>
+ </section>
+
+ <section>
+ <h2> Media types</h2>
+ <p>Printed web documents generally have pixelated images due to printers having a higher DPI than most images currently served on the web. 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 inkjet printer sprays ink through tiny nozzles, and is typically capable of 300-600 DPI. A laser printer applies toner through a controlled electrostatic charge, and may be in the range of 600 to 1,800 DPI."</p>
+ </blockquote>
+ <p>Defining higher resolution images for printing would increase the abilities of web developers to define printed versions of their documents. For example, a photo sharing site could provide a bandwidth-optimized image for display on screen, but a high-resolution image for print. </p>
+ </section>
+ <section>
+ <h2>Monochrome and high-contrast </h2>
+ <p>Displaying a color image on monochrome media is not always ideal (e.g., on paper an e-ink displays). This is because two different colors of similar luminosity are impossible to distinguish on monochrome media. Serving images specifically for monochrome media can help overcome this issue. </p>
+ <p>Currently, server side solutions exist to adapt web content to e-ink displays. For example, <a href="http://kinstant.com/">http://kinstant.com/</a>. Or custom services have been created specifically for accessing popular websites, like <a href="http://www.kindletwit.com/">www.kindletwit.com</a>. </p>
+ <p>Additionally, Microsoft is <a href="http://msdn.microsoft.com/en-us/library/windows/apps/hh465764.aspx">proposing a "high-contrast" media feature</a>, which enables developers to know if the user agent is operating in a high-contrast mode. Knowing if the user agent is operating in high-contrast mode allows developers to serve appropriate images, which could potentially assists visually impaired users. To be able to use such a solution with images on the Web, developers would currently need to rely on the problematic <a href="http://css-tricks.com/which-responsive-images-solution-should-you-use/">techniques</a> previously discussed. </p>
+ </section>
+ <section>
+ <h2>Mobile-first and desktop-first responsive design</h2>
+ <p>A common approach in sites that cater to a wide range of devices using a single codebase is a “mobile-first” development pattern—starting with a simple, linear layout and increasing layout and functional complexity for larger screen sizes using media queries. In such designs, web developers generally serve appropriately sized images first and increase the size of images as required for the available dimensions. </p>
+ <p>“Desktop-first” responsive design takes the opposite approach and starts from the desktop design and simplifies it using media queries to support small displays. Developers retrofitting existing sites often take a desktop-first approach out of necessity because changing to a mobile-first approach would be a significant undertaking. </p>
+ <p>In such cases, providing both a range of images to match the available dimensions, as well as a fallback for legacy user agents, is desirable. Current <a href="http://css-tricks.com/which-responsive-images-solution-should-you-use/">techniques</a> are problematic in that they rely on scripting and the <code>noscript</code> element to work.</p>
+ </section>
+ <section>
+ <h2>Relative units</h2>
+ <p>A common practice in creating flexible layouts is to specify the size values in media queries as relative units: <code>em</code>, <code>rem</code>, <code>vw</code>/<code>vh</code> etc. See, for example, Lyza Gardner's article <a href="http://blog.cloudfour.com/the-ems-have-it-proportional-media-queries-ftw/">The EMs have it: Proportional Media Queries FTW!</a>. This approach is most commonly seen using <code>em</code>s in order to reflow layouts based on users’ zoom preferences, or to resize elements through JavaScript by dynamically altering a font-size value. </p>
+ <p>In flexible layout designs, when a user zooms into an design, images get proportionally scaled and can become blurry or pixelated potentially affecting the image's ability to communicate as the developer intended (or simply looks ugly, which is also unacceptable). Swapping to a more suitable image is used to overcome this problem. </p>
+
+ </section>
+
+<section>
+ <h2>Dynamically acquired images data </h2>
+ <p>There are cases where the image data may be dynamically generated (e.g., using <code>canvas</code> element and related APIs) or may be acquired from the device itself (e.g., from the camera). In such cases, a practical means to interface programmatically with an image or a set of images is often necessary. Without having a suitable API, it will be difficult for developers to manipulate the sources of images. </p>
+</section>
+</section>
+
+<section id="requirements">
+<h1>Requirements</h1>
+<p>The <a>use cases</a> give rise to the following <dfn>requirements</dfn>:</p>
+<ul>
+ <li>
+ <p>The <a>solution</a> MUST afford developers the ability to match image sources with particular media features and/or media types - and have the user agent update the source of an image as the media features and media types of the browser environment change dynamically over time. </p>
+ </li>
+ <li>
+ <p>The <a>solution</a> MUST degrade gracefully on legacy user agents by, for example, falling back on the <code>img</code> element and by relying on [[HTML5]] built-in fallback mechanisms.</p></li>
+ <li>
+ <p>The <a>solution</a> MUST allow developers to provide textual descriptions of text content for images using [[HTML5]] markup. This helps overcome some of the limitations inherent in the image element's <code>alt</code> attribute, particularly relating to internationalization.</p></li>
+ <li>
+ <p>The <a>solution</a> MUST adhere to akin solutions already in [[HTML5]], such as those used by <code>audio</code> and <code>video</code> elements.</p></li>
+ <li><p>The <a>solution</a> MUST NOT require any server-side processing. </p></li>
+ <li>
+ <p>The <a>solution</a> MUST provide developers with a means to programmatically interface with the displayed image, as well as access relevant attributes and methods that make solution easy to work with. In addition, the solution MUST provide means to hook into relevant events (e.g., loading, errors, etc.). In any case, an API SHOULD provide a means to:</p>
+ <ul>
+ <li>
+ <p> Determine the current source of the image.</p>
+ </li>
+ <li>
+ <p>Determine what environmental condition caused the current source to be selected (reflected as, for example, a CSS Media Query). </p>
+ </li>
+ <li>
+ <p>Add, remove, and update image sources.</p>
+ </li>
+ </ul>
+ </li>
+ <li>
+ <p>The <a>solution</a> MUST afford developers the ability to explicitly define different image versions as opposed to simply different resolutions of the same image. </p>
+ </li>
+ <li>
+ <p>The <a>solution</a> MUST afford developers the ability to define fallback image as the smallest image (mobile first) or the largest image (desktop first).</p>
+ </li>
+ <li>
+ <p> The <a>solution</a> MUST 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>solution</a> MUST function in such a way that is is responsive to environmental changes in relative units (e.g., when the user increases the base font size of the browser by pressing <kbd>ctrl+</kbd> or <kbd>ctrl-</kbd>).</p>
+ </li>
+ <li>
+ <p>To provide compatibility with legacy user agents, it SHOULD be possible for developers to <a href="http://remysharp.com/2010/10/08/what-is-a-polyfill/">polyfill</a> the <a>solution</a>.</p>
+ </li>
+</ul>
+</section>
+
+<section>
+ <h1>Open issues</h1>
+ <p>We are tracking <dfn>open issues</dfn> on Github. <a href="https://github.com/ResponsiveImagesCG/ri-usecases/issues">Please help close them</a>! </p>
+ <div id="open-issues-xhr"></div>
+</section>
+<section>
+ <h1>Acknowledgements</h1>
+ <p>We would like to thank the following people for reviewing the specification: Mike Taylor, Doug Shults. </p>
+</section>
+<script src="https://raw.github.com/ResponsiveImagesCG/meta/master/scripts/show_issues.js"></script>
+<script src="https://api.github.com/repos/ResponsiveImagesCG/ri-usecases/issues?state=open&callback=processResponse"></script>
+</body>
+</html>
\ No newline at end of file