--- a/responsive-images/responsive-images.html Tue Sep 25 16:32:15 2012 -0400
+++ b/responsive-images/responsive-images.html Tue Oct 09 10:43:52 2012 -0400
@@ -1,103 +1,162 @@
<!DOCTYPE html>
<html>
<head>
- <title>The picture Element and the srcset attribute</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: "ED",
- shortName: "respimg",
- noIDLSorting: true,
- edDraftURI: "http://dvcs.w3.org/hg/html-proposals/raw-file/tip/responsive-images/responsive-images.html",
+<title>The picture element</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: "ED",
+ shortName: "respimg",
+ noIDLSorting: true,
+ edDraftURI: "http://dvcs.w3.org/hg/html-proposals/raw-file/tip/responsive-images/responsive-images.html",
- editors: [
- {
- name: "Marcos Cáceres, current",
- company: "Responsive Images Community Group",
- companyURL: "http://www.w3.org/community/respimg/"
- },
- {
- name: "Mat Marquis, current",
- 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/Wilto/draft-prop/issues",
- noIDLSectionTitle: true
- };
- </script>
- <style type="text/css">
+ 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/Wilto/draft-prop/issues",
+ noIDLSectionTitle: true
+ };
+ </script>
+<style type="text/css">
.informative {
- background-color: rgb(233, 251, 233);
+ background-color: rgb(233, 251, 233);
}
ol > li {
- margin-bottom: 1em;
+ margin-bottom: 1em;
}
#conformance dd {
- margin-bottom: 1em;
+ margin-bottom: 1em;
}
pre {
- tab-size: 3; /* Reduce indentation. */
+ tab-size: 3; /* Reduce indentation. */
}
.informative-subhed {
- font-size: 120%;
+ font-size: 120%;
}
- a{ color: blue}
- a:not([href]) { color: red}
+a {
+ color: blue
+}
+a:not([href]) {
+ color: red
+}
</style>
- </head>
- <body>
- <section id='abstract'>
- <p>Through the combination of a new <code>picture</code> element and a new the <code>srcset</code> attribute for the existing <code>source</code> element, this specification adds functionality to HTML that allows authors to list a range of images which may be suitable for a range of device capabilities and different usage scenarios. The ability to adapt content to the constraints and capabilities of devices and different usage scenarios is commonly referred to as "responsive design".
- This allows user agents to be more responsive to a wide spectrum of browsing scenarios, ranging from simple mobile devices to desktop browsers scenarios, when selecting which image resources to download and display for an end-user. This includes, but is not limited to, the selection of images most suited for either high or low density displays and screen resolutions on range of devices, are well as responsive selection of images based on printer's dpi and color reproduction capabilities.</p>
- </section>
-
- <section id="goals">
- <h1>Goals</h1>
- <p>The overarching goal is to give developers a way to provide user agents with sufficient information about each image, and applicable media, so that the user agent can select the most appropriate one for a dynamically changing browsing situations. This includes, but is not limited to, different screen pixel width/height, pixel densities, environmental lighting conditions, and potentially even situations where the network bandwith changes dymamically. By providing a graded set of image sources, UA discretion could similarly apply to situations where the network bandwith changes dymamically. Based on user settings and network latency calculated by the user agent, the UA may have the option of selecting lower density image sources.</p>
- <p>In addition, this proposal is being worked on with the following goals in mind:</p>
- <ul>
- <li>Will degrade gracefully on older user agents.</li>
- <li>Can be polyfilled.</li>
- <li>Retains, at a minimum, the same level of accessibility as current <code>img</code> element - and we may even be able to do better! </li>
- <li>Adhere to common conventions around for content, markup, behavior, and styling.</li>
- <li>Provides a purely client-side solution that can rely on scripts, but doesn’t require it. Similarly, this solution must not require the use of any server-side technologies to reliably deliver content tailored for the end user’s browsing situation.</li>
- <li>Supports use cases where authors need to explicitly define different image versions as opposed to simply different resolutions of the same image.</li>
- <li>Provides a consistent and predictable pattern for delivering alternate media sources based on client context.</li>
- <li>Supports succinct but understandable mark-up. </li>
- <li>Don't repeat yourself: If the same image is used multiple times on a single page, it would be useful to define the resource selection in a single place in the document and have this affect all instances of the image</li>
- </ul>
- </section>
-
-
+</head>
+<body>
+<section id='abstract'>
+ <p>The <code>picture</code> element is an image whose source content is determined by one or more CSS media queries.</p>
+</section>
+<section id="introduction" class="informative">
+ <h1>Introduction</h1>
+ <p>This specification provides developers with a means to declare multiple sources for an image - and through <cite>CSS Media Queries</cite> ([[!CSS3-MEDIAQUERIES]]), it gives developers control as to when those images are to be presented to the user. By relying on [[!CSS3-MEDIAQUERIES]], the user agent "responds" to the browsing environment to select the image source that most closely matches the browsing environment - thus embodying a technique known as <a href="http://en.wikipedia.org/wiki/Responsive_web_design">responsive web design</a> directly into HTML markup. Potential media quires that a browser can respond to include, but are not limited to, pixel widths and heights, and pixel densities, as well as environmental lighting conditions, changes in orientation, and even changes in media type (e.g., going from screen to print).</p>
+ <p>This is achieved by introducing a new a <code>picture</code> element and using <code>source</code> element as its children. The <code>picture</code> element remain backwards compatible with legacy user agents, by degrading gracefully through fallback content (e.g., the img element) while also providing better accessibility than the existing <code>img</code> element. </p>
+ <section>
+ <h2>Example of usage</h2>
+ <p>This first sample shows how to combine the <code>picture</code> element with the source element, while also providing fallback content for legacy user agents through the <code>img</code> element. </p>
+ <pre class="example"><picture width="500" height="500">
+ <source media="(min-width: 45em)" src="large.jpg">
+ <source media="(min-width: 18em)" src="med.jpg">
+ <source src="small.jpg">
+ <img src="small.jpg" alt="">
+ <p>Accessible text</p>
+</picture>
+</pre>
+ </section>
+ <div class="issue">
+ <p>The following example assumes we can get <a href="http://dev.w3.org/html5/srcset/">the <code>srcset</code> attribute</a> supported on HTML's <code>source</code> element. See <a href="https://github.com/Wilto/draft-prop/issues/64">issue 64</a>.</p>
+ </div>
+ <p>This second example shows how the <code>picture</code> element can use used with <a href="http://dev.w3.org/html5/srcset/">the <code>srcset</code> attribute</a> to provide a range of sources suitable for a given media query:</p>
+ <pre class="example"><picture width="500" height="500">
+ <source media="(min-width: 45em)" srcset="large-1.jpg 1x, large-2.jpg 2x">
+ <source media="(min-width: 18em)" srcset="med-1.jpg 1x, med-2.jpg 2x">
+ <source srcset="small-1.jpg 1x, small-2.jpg 2x">
+ <img src="small-1.jpg" alt="">
+ <p>Accessible text</p>
+</picture></pre>
+</section>
+<section>
+ <section>
+ <h2>Goals</h2>
+ <p>This specification aims was written to meet the following goals. The following lists the goals and how those goals are met by this, or by dependent, specifications:</p>
+ <dl>
+ <dt>Will degrade gracefully on older user agents:</dt>
+ <dd>
+ <p>Using the <code>img</code> element, and by relying on [[!HTML5]] built in fallback mechanisms, the proposed solution degrades gracefully on legacy user agents. </p>
+ </dd>
+ <dt>Can be polyfilled.</dt>
+ <dd>
+ <p>Polyfills exist and are documented on our <a href="https://github.com/Wilto/draft-prop/wiki/Polyfills,-prototypes,-and-reference-imps">wiki</a>. </p>
+ </dd>
+ <dt>Retains, at a minimum, the same level of accessibility as current <code>img</code> element:</dt>
+ <dd>
+ <div class="issue">
+ <p class="TODO"><strong>TODO</strong>: need Steve Faulkner and others to confirm we have met this goal. </p></div>
+ </dd>
+ <dt>Adhere to common conventions around for content, markup, behavior, and styling:</dt>
+ <dd>
+ <p>Follows conventions set by the [[!HTML5]]<code> audio</code> and <code>video</code> elements. </p>
+ </dd>
+ <dt>Does not require the use of server-side technologies to reliably deliver content tailored for the end user’s browsing situation: </dt>
+ <dd>
+ <p>The picture element, together with the source element, provide a complete solution for meeting the <a>use cases</a>.</p>
+ </dd>
+ <dt>Supports cases where authors need to explicitly define different image versions as opposed to simply different resolutions of the same image:</dt>
+ <dd>
+ <p>This is achieved through reliance on the <code>source</code> element's <code>media</code> attribute. </p>
+ </dd>
+ <dt>Provides a consistent and predictable pattern for delivering alternate media sources based on the browsing environment:</dt>
+ <dd>
+ <p>This is achieved through reliance on the <code>source</code> element's <code>media</code> attribute.</p>
+ </dd>
+ </dl>
+ </section>
+ <section>
+ <h2>Differences from <code>img</code> element</h2>
+ <p>Unlike the <code>img</code> element and its current <a href="http://dev.w3.org/html5/srcset/"><code>srcset</code> attribute</a>, the <code>picture</code> element is intended to allow an author to reference many different image sources and associate those image sources with a CSS media query [[!CSS3-MEDIAQUERIES]]. The <code>srcset</code> attribute of the <code>img</code> element only allows matching on display dimensions and pixel densities, and the user agent is not required to respect the author's declared desires. </p>
+ <p>The browser dynamically updates the displayed image based on the browsing environment. This means that the developer determines the most suitable image for the browsing environment. Or the most suitable image source may be a different version of an image that has been modified by the author to be suitable for a particular use (see: <a>art direction</a> use case). </p>
+ </section>
+</section>
<section id="sotd">
- <p>This document was proposed by the <a href="http://www.w3.org/community/respimg/">Responsive Images Community Group</a> as a solution to <a href="https://www.w3.org/Bugs/Public/show_bug.cgi?id=18384">bug 18384</a>.</p>
- </section>
-
-
+ <div class="note">
+ <p>This specification is under active development and changing frequently. Please see the list of <a>open issues</a>.</p>
+ </div>
+ <p>This document was proposed by the <a href="http://www.w3.org/community/respimg/">Responsive Images Community Group</a> as a solution to <a href="https://www.w3.org/Bugs/Public/show_bug.cgi?id=18384">bug 18384</a>.</p>
+</section>
<section id="conformance">
- <p>This specification describes the conformance criteria for <dfn title="user agent">user agents</dfn> (relevant to implementors) and <dfn title="document">documents</dfn> (relevant to authors and authoring tool implementors).</p>
- <p>Implementations that use ECMAScript to expose the APIs defined in this specification MUST implement them in a manner consistent with the ECMAScript Bindings defined in the Web IDL specification [[!WEBIDL]].</p>
- </section>
+ <p>This specification has the same <a href="http://dev.w3.org/html5/spec/single-page.html#conformance-requirements">conformance requirements</a> and applies to the same <a href="http://dev.w3.org/html5/spec/single-page.html#conformance-classes">conformance classes</a> as [[!HTML5]].
+ <p>Implementations that use ECMAScript to expose the APIs defined in this specification MUST implement them in a manner consistent with the ECMAScript Bindings defined in the [[!WEBIDL]] specification.</p>
+</section>
<section id="definitions">
- <h1>Definitions</h1>
- <p>The following terms are used throughout this specification so they are gathered here for the readers convenience. The following list of terms is not exhaustive; other terms are defined throughout this specification.</p>
- <p>The follow terms are defined by the<cite> </cite>[[!HTML5]] specification: <dfn><a href="http://www.w3.org/TR/html5/the-img-element.html#the-img-element"><code>img</code> element</a></dfn>, <dfn><a href="http://www.w3.org/TR/html5/the-source-element.html#the-source-element"><code>source</code> element</a></dfn>, <dfn><a href="http://www.w3.org/TR/html5/media-elements.html#media-resource"><code>media</code> resource</a></dfn>, <dfn><a href="http://www.w3.org/TR/html5/content-models.html#fallback-content">fallback content</a></dfn>, <dfn><a href="http://www.w3.org/TR/html5/urls.html#valid-non-empty-url-potentially-surrounded-by-spaces">valid non-empty URL potentially surrounded by spaces</a></dfn> and <dfn><a href="http://www.w3.org/TR/html5/common-microsyntaxes.html#valid-media-query">valid media query</a></dfn>.</p>
- <p>The <dfn><a href="http://dev.w3.org/csswg/css4-images/#image-set-notation">image-set notation</a></dfn> microsyntax is defined by the<cite> CSS Image Values and Replaced Content Module Level 4 Specification</cite> [[!CSS4-IMAGES]].</p>
- <p>The <dfn><a href="http://www.w3.org/TR/html-alt-techniques/#secm1">techniques for providing useful text alternatives for <code>img</code> elements</a></dfn> are defined by the <cite>HTML5: Techniques for providing useful text alternatives</cite> Specification [[!ALT-TECHNIQUES]].</p>
- </section>
+ <h1>Definitions</h1>
+ <p>The following terms are used throughout this specification so they are gathered here for the readers convenience. The following list of terms is not exhaustive; other terms are defined throughout this specification.</p>
+ <p>The follow terms are defined by the<cite> </cite>[[!HTML5]] specification: <dfn><a href="http://www.w3.org/TR/html5/the-img-element.html#the-img-element"><code>img</code> element</a></dfn>, <dfn><a href="http://www.w3.org/TR/html5/the-source-element.html#the-source-element"><code>source</code> element</a></dfn>, <dfn><a href="http://www.w3.org/TR/html5/media-elements.html#media-resource"><code>media</code> resource</a></dfn>, <dfn><a href="http://www.w3.org/TR/html5/content-models.html#fallback-content">fallback content</a></dfn>, <dfn><a href="http://www.w3.org/TR/html5/urls.html#valid-non-empty-url-potentially-surrounded-by-spaces">valid non-empty URL potentially surrounded by spaces</a></dfn> and <dfn><a href="http://www.w3.org/TR/html5/common-microsyntaxes.html#valid-media-query">valid media query</a></dfn>. </p>
+</section>
<section>
- <h1>The <code>picture</code> element</h1>
- <dl>
+ <h1>The <code>picture</code> element</h1>
+ <dl>
<dt><a href="http://dev.w3.org/html5/spec/single-page.html#element-dfn-categories" title="element-dfn-categories">Categories</a>:</dt>
<dd><a href="http://dev.w3.org/html5/spec/single-page.html#flow-content-1">Flow content</a>.</dd>
<dd><a href="http://dev.w3.org/html5/spec/single-page.html#phrasing-content-1">Phrasing content</a>.</dd>
@@ -111,8 +170,7 @@
<dd>Zero or one <code>img</code> element, serving as <a>fallback content</a>.</dd>
<dt><a href="http://dev.w3.org/html5/spec/single-page.html#element-dfn-attributes" title="element-dfn-attributes">Content attributes</a>:</dt>
<dd><a href="http://dev.w3.org/html5/spec/single-page.html#global-attributes">Global attributes</a></dd>
- <dd><code>crossorigin</code></dd>
- <dd><code>ismap</code></dd>
+
<dd><code>width</code></dd>
<dd><code>height</code></dd>
<dt><a href="http://dev.w3.org/html5/spec/single-page.html#element-dfn-dom" title="element-dfn-dom">DOM interface</a>:</dt>
@@ -123,75 +181,43 @@
HTMLPictureElement : HTMLImageElement{
readonly attribute DOMString media;
}</pre>
-
</dd>
</dl>
- <p>The <code><dfn>picture</dfn></code> element used for displaying an image that can come from a range of sources (see <code>srcset</code> attribute). Which image the user agent displays depends on the
- <a>algorithm for deriving the source image</a>. </p>
- <p>On getting the <code>media</code> attribute, the user agent MUST return the </p>
- <p>The <a>chosen image</a> is the embedded content. </p>
- <p>For user agents that don't support the <code>picture</code> element, an author can provide an <code>img</code> element as <a>fallback content</a>. User agents SHOULD NOT show this content to the user: it is intended for legacy user agents that do not support <code>picture</code>, so that a legacy <code>img</code> element can be shown instead.</p>
- <p>Authoring requirement: as with the <code>img</code> element, documents must not use the <code>picture</code> element as a layout tool. In particular, picture elements should not be used to display transparent images, as they rarely convey meaning and rarely add anything useful to the document. </p>
- <section><h2>Example of usage</h2>
- <p>Sample picture element markup:</p>
- <pre class="example"><picture width="500" height="500">
- <source media="(min-width: 45em)" srcset="large-1.jpg 1x, large-2.jpg 2x">
- <source media="(min-width: 18em)" srcset="med-1.jpg 1x, med-2.jpg 2x">
- <source srcset="small-1.jpg 1x, small-2.jpg 2x">
- <img src="small-1.jpg" alt="">
- <p>Accessible text</p>
-</picture></pre></section>
- <section>
- <section><h2>Differences from <code>img</code> element</h2>
- <p>Unlike the <code>img</code> element, which is limited to pointing to a single image resource, the <code>picture</code> element is intended to allow an author to reference many different image sources that the browser can then choose based on a <a>media query</a> or some other relevant browsing situation or constraint. This means that a user agent can best select an image source that is most suitable for available display size, pixel density, or possibly even network bandwidth. Or the most suitable image source may be a different version of an image that has been modified by the author to be suitable for a particular use (see: <a>art direction</a> use case). </p>
- <p>It is RECOMMENDED that for cases where a single image source is available, and where no responsive adoption is needed, authors use the <code>img</code> element. </p></section>
- </section>
- <!-- / picture permitted attributes -->
-
- <section>
- <p>When used with the <code>picture</code> element, a <a>document</a> SHOULD only contain <code>source</code> elements need to represent the same subject matter, but cropping and zooming can differ.</p>
- <div class="issue">It should be codified that this is not a mechanism by which to swap disparate images depending on screen size. See bug <a href="https://www.w3.org/Bugs/Public/show_bug.cgi?id=18384#c7">18384</a>.</div>
- </section>
-
-
-
- </section>
-
-
- <section>
- <h1>The <code>srcset</code> attribute </h1>
- <p>The <dfn><code>srcset</code> attribute</dfn> of the <code>source</code> element is is used to refer to alternate <a>image resource</a> for a single image at different resolutions. The expected value of the attribute is a comma-separated list of <a>valid non-empty URL potentially surrounded by spaces</a> that matches the <code>valid-srcset</code> production: </p>
- <pre><dfn>valid-srcset</dfn> = [ image-set-decl "," ]* [ image-set-decl ]
-image-set-decl = <a href="http://www.w3.org/TR/2011/REC-CSS2-20110607/syndata.html#uri">uri</a> resolution</pre>
- <p>The <code><a href="http://www.w3.org/TR/2011/REC-CSS2-20110607/syndata.html#uri">uri</a></code> component is defined in [[!CSS21]] and the <code>resolution</code> component is defined in the<cite> CSS Image Values and Replaced Content Module Level 4 Specification</cite> [[!CSS4-IMAGES]].</p>
- <section>
- <h2>Example</h2>
- <p>The following is an example of a <code>valid-srcset</code>.</p>
- <pre class="example">large-1.jpg 1x, large-2.jpg 2x </pre>
- </section>
- </section>
-
-
+ <p>The <code><dfn>picture</dfn></code> element used for displaying an image that can come from a range of sources (see <code>srcset</code> attribute). Which image the user agent displays depends on the <a>algorithm for deriving the source image</a>. </p>
+ <p>On getting the <code>media</code> IDL attribute, the user agent MUST return the media query that matches the current environment. </p>
+ <p>It is RECOMMENDED that for cases where a single image source is available, and where no responsive adoption is needed, authors use the <code>img</code> element. </p>
+</section>
+<p>The <a>chosen image</a> is the embedded content. </p>
+<p>For user agents that don't support the <code>picture</code> element, an author can provide an <code>img</code> element as <a>fallback content</a>. User agents SHOULD NOT show this content to the user: it is intended for legacy user agents that do not support <code>picture</code>, so that a legacy <code>img</code> element can be shown instead.</p>
+<p>Authoring requirement: as with the <code>img</code> element, documents must not use the <code>picture</code> element as a layout tool. In particular, picture elements should not be used to display transparent images, as they rarely convey meaning and rarely add anything useful to the document. </p>
+<section>
+ <p>When used with the <code>picture</code> element, a <a>document</a> SHOULD only contain <code>source</code> elements need to represent the same subject matter, but cropping and zooming can differ.</p>
+ <div class="issue">
+ <p>It should be codified that this is not a mechanism by which to swap disparate images depending on screen size. See bug <a href="https://www.w3.org/Bugs/Public/show_bug.cgi?id=18384#c7">18384</a>.</p>
+ </div>
+</section>
+</section>
+</section>
<section id="algorithms">
<h1>Algorithm for deriving the source image</h1>
<p>The <dfn>algorithm for deriving the source image</dfn> as follows. The result is the image source to be used by the <code>picture</code> element, which reflects the <code>picture</code> element's <a><code>src</code> IDL attribute</a>: </p>
-<div class="note">
-<p>What we want to do is have the <code>picture</code> behave exactly the same as an <code>img</code> element, but with the only difference being that it is <code>source</code> elements is used to determine the value of the <code>src</code> IDL attribute (and hence what image content is displayed). How that is determined is through using the <code>media</code> attribute attribute of the <code>source</code> element. </p>
-<p>To avoid complexity, the <code>type</code> attribute is all child <code>source</code> elements is ignored in this context. </p>
-<p>So, to derive the <dfn>source image</dfn>: we gather all the media queries from the <code>source</code> elements' <code>media</code> attributes into a "stylesheet", in document order. Any missing <code>media</code> attributes are just assumed to mean "all". Any media attributes that are not valid media queries are ignored. So, given the following: </p>
-<pre><picture id="pictureElement">
+ <div class="note">
+ <p>What we want to do is have the <code>picture</code> behave exactly the same as an <code>img</code> element, but with the only difference being that it is <code>source</code> elements is used to determine the value of the <code>src</code> IDL attribute (and hence what image content is displayed). How that is determined is through using the <code>media</code> attribute attribute of the <code>source</code> element. </p>
+ <p>To avoid complexity, the <code>type</code> attribute is all child <code>source</code> elements is ignored in this context. </p>
+ <p>So, to derive the <dfn>source image</dfn>: we gather all the media queries from the <code>source</code> elements' <code>media</code> attributes into a "stylesheet", in document order. Any missing <code>media</code> attributes are just assumed to mean "all". Any media attributes that are not valid media queries are ignored. So, given the following: </p>
+ <pre><picture id="pictureElement">
<span class="example"> <source media="(min-width: 45em)" srcset="large-1.jpg 1x, large-2.jpg 2x">
- <source media="(min-width: 18em)" srcset="med-1.jpg 1x, med-2.jpg 2x">
+ <source media="(min-width: 18em)" srcset="med-1.jpg 1x, med-2.jpg 2x">
<!-- assume media all -->
- <source srcset="small-1.jpg 1x, small-2.jpg 2x"></span>
+ <source srcset="small-1.jpg 1x, small-2.jpg 2x"></span>
<!-- the following are ignored -->
-<span class="example"> <source media=" is the massage " srcset="">
+<span class="example"> <source media=" is the message " srcset="">
</span>
</picture></pre>
-<p>Becomes the rough CSS equivalent of (a virtual stylesheet for the document?):</p>
-<pre>
+ <p>Becomes the rough CSS equivalent of (a virtual stylesheet for the document?):</p>
+ <pre>
//assume #pictureElement is magically scoped to the corresponding element.
@media all{
@@ -211,100 +237,121 @@
background-image: image-set(<span class="example">med-1.jpg 1x, med-2.jpg 2x</span>);
}
}</pre>
-<p>The API then just works the same as per images. Events are fired in the same way as if the image's src IDL attribute had been set manually by the author. </p>
-<p>The resource fetching behavior of then governed by <cite>CSS Image Values and Replaced Content Module Level 4</cite>.</p>
-</div>
-
-
-
-<p>A user agent MAY override requests for higher-resolution images based on user preferences. For example: “always request high-resolution images,” “always request low-resolution images,” and “request high-resolution images as bandwidth permits” based on the bandwidth information available to the browser.</p>
-
- </section>
-<!-- /algorithms -->
-
-
-
-<section id="examples" class="informative">
- <h1>Examples</h1>
- <p>TODO: add examples</p>
- </section>
-<!-- examples -->
-
-<section id="use-cases" class="appendix informative">
- <h1>Use Cases </h1>
-Cosmetic changes and removed some attribute defs that are not inherited from HTMLImageInterface
- <p>There are many use cases that are supported as listed below. There are two primary use cases:</p>
- <ol>
+ <p>The API then just works the same as per images. Events are fired in the same way as if the image's src IDL attribute had been set manually by the author. </p>
+ <p>The resource fetching behavior of then governed by <cite>CSS Image Values and Replaced Content Module Level 4</cite>.</p>
+ </div>
+ <p>A user agent MAY override requests for higher-resolution images based on user preferences. For example: “always request high-resolution images,” “always request low-resolution images,” and “request high-resolution images as bandwidth permits” based on the bandwidth information available to the browser.</p>
+</section>
+<section id="use-cases" class="appendix informative">
+ <h1>Use cases </h1>
+ <p>There are many use cases that are supported as listed below. There are two primary use cases:</p>
+ <ol>
<li>The need for different image sources at different viewport sizes in responsive web designs.</li>
<li>The need for different image sources depending on the pixel density of the display.</li>
</ol>
- <p>Most of the more specific use cases fall under one of these two umbrella needs.</p>
- <h2 class="informative-subhed">Viewport Sizes</h2>
- <p>There are many different screen sizes that are in common daily usage, ranging from small phones to giant high-definition televisions. This change in how we access the web was the main reason for needing to make responsive websites in the first place.</p>
- <p>A common practice in responsive design is delivering images without height and width attributes and letting the browser resize the image. This technique is commonly called flexible images or fluid images.</p>
- <p>However, delivering an image at a size optimized for large displays to a small display is not ideal. Large images incur unnecessary download and processing time, slowing the experience for users.</p>
- <p>To solve this problem, web authors will 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 authors lack the tools to do so for images in HTML without the use of JavaScript.</p>
- <h2 class="informative-subhed">Display Density</h2>
- <p>Since the high-density devices (e.g., Retina™ displays on Apple products) came out, the quality of images on the web has changed. Beforehand, even though we had a variety of device sizes, the DPI has always been the same. This is no longer the case and it is very likely that the current resolution/pixel density on Retina™ devices will not be the only one.</p>
- <p>We should be ready and able to support the current resolutions as well as any others that manufacturers may use in the future.</p>
- <h2 class="informative-subhed">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.</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. Authors 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>These two approaches require that a solution for images support the following:</p>
- <ul>
- <li>Authors need the ability to define fallback image as the smallest image (mobile first) or the largest image (desktop first).</li>
- <li>Authors would like 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.</li>
- </ul>
- <h2 class="informative-subhed">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. This is most commonly seen using ems in order to reflow layouts based on users’ zoom preferences, or to resize elements through JavaScript by dynamically altering a font-size value.</p>
- <h2 class="informative-subhed">Matching image source breakpoints to design breakpoints</h2>
- <p>Web authors would like to be able to optionally match the breakpoints for images to the breakpoints that they have defined in their responsive designs. Being able to match the breakpoints ensures that images are operating under the same rules that define the layout. It also helps authors verify their approach by ensuring that the same viewport measurement tests are being used in both HTML and CSS.</p>
- <p>This desire is a facet of the two preceding use cases (mobile/desktop-first responsive design and relative units). If a breakpoint in the design is defined as:</p>
- <p><code>@media screen (max-width: 41em) {}</code></p>
- <p>Then web authors 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 authors.</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 author would need to specify 657 pixels as a minimum width for the breakpoint.</li>
- </ul>
- <p>When debugging a document, if the author cannot specify breakpoints for images in the same manner that they are defined for the design, authors 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 that math errors on the part of authors (possibly due to a different rounding scheme in a particular user agent) cause unexpected behavior.</p>
- <h2 class="informative-subhed">Mobile Networks</h2>
- <p>It should be noted that many devices are used on mobile networks which are often very slow or exhibit high latency. Often times conferences suffer from slow networks as well due to many users attempting to use a single network connection simultaneously. Many people also have very slow or erratic connections in their homes and workplaces. While it may not be possible for a solution to be based on bandwidth, anything that can be done to reduce latency and HTTP requests should be done.</p>
- <p>Allowing authors to specify different images for different viewport sizes and display densities is one step towards providing a better experience on slow networks. In the future, user agents may be able to select different images based on network speed or user preference.</p>
- <h2 class="informative-subhed">User Zoom</h2>
- <p>Images blur when the user resizes the page. Users may zoom an image in order to see more detail. In these cases, user agents could select a higher-resolution version of an image to display.</p>
- <div class="issue">It's not clear whether the picture element is prescriptive (i.e. the user agent MUST show a particular image given certain device properties) or suggestive (i.e. the user agent has control over picking the best image).</div>
- <h2 class="informative-subhed">Art Direction</h2>
- <p>Web authors often want to provide different versions of the same image at different sizes depending on the viewport. We refer to this as the <dfn>a rt direction</dfn> use case.</p>
- <p>A simple example of this would be changing the crop of an image based on display area:</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 device, 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>Examples: <a href="http://blog.cloudfour.com/a-framework-for-discussing-responsive-images-solutions/#artdirection">Large photo of Obama at a Chrysler plant vs. tighter cropped thumbnail</a></p>
- <p>A more complex example that changes orientation of the image, crop, and how text flows around an image based on the size of the viewport:</p>
- <ul>
- <li>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 img to vertical made more sense because it allowed the reader to still make out the features of the browser in the image.</li>
- </ul>
- <h2 class="informative-subhed">Alternate Print Sources</h2>
- <p>Printed web documents generally have pixelated images due to printers having a higher DPI than most images currently served on the web. Defining higher resolution images for printing would increase the abilities of web authors to define great 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>
- <h2 class="informative-subhed">Gray Scale and High Contrast Modes</h2>
- <p>Displaying a color image on a monochrome display does not always work well, as two different colors of similar luminosity would be impossible to distinguish in a monochrome environment.</p>
- <p>Microsoft is proposing a media query which lets you <a href="http://msdn.microsoft.com/en-us/library/windows/apps/hh465764.aspx">detect that the user agent has been put in high contrast mode</a> (for accessibility reasons), and that the content should follow along. Being able to switch images based on high contrast mode would be nice.</p>
- <p>Extracted from <a href="http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-August/036845.html">WhatWG mailing list thread</a>.</p>
- </section>
-<!-- use-cases -->
+ <p>Most of the more specific use cases fall under one of these two umbrella needs.</p>
+ <section>
+ <h2 class="informative-subhed">Viewport Sizes</h2>
+ <p>There are many different screen sizes that are in common daily usage, ranging from small phones to giant high-definition televisions. This change in how we access the web was the main reason for needing to make responsive websites in the first place.</p>
+ <p>A common practice in responsive design is delivering images without height and width attributes and letting the browser resize the image. This technique is commonly called flexible images or fluid images.</p>
+ <p>However, delivering an image at a size optimized for large displays to a small display is not ideal. Large images incur unnecessary download and processing time, slowing the experience for users.</p>
+ <p>To solve this problem, web authors will 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 authors lack the tools to do so for images in HTML without the use of JavaScript.</p>
+ </section>
+ <section>
+ <h2 class="informative-subhed">Display Density</h2>
+ <p>Since the high-density devices (e.g., Retina™ displays on Apple products) came out, the quality of images on the web has changed. Beforehand, even though we had a variety of device sizes, the DPI has always been the same. This is no longer the case and it is very likely that the current resolution/pixel density on Retina™ devices will not be the only one.</p>
+ <p>We should be ready and able to support the current resolutions as well as any others that manufacturers may use in the future.</p>
+ </section>
+ <section>
+ <h2 class="informative-subhed">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.</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. Authors 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>These two approaches require that a solution for images support the following:</p>
+ <ul>
+ <li>Authors need the ability to define fallback image as the smallest image (mobile first) or the largest image (desktop first).</li>
+ <li>Authors would like 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.</li>
+ </ul>
+ </section>
+ <section>
+ <h2 class="informative-subhed">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. This is most commonly seen using ems in order to reflow layouts based on users’ zoom preferences, or to resize elements through JavaScript by dynamically altering a font-size value.</p>
+ </section>
+ <section>
+ <h2 class="informative-subhed">Matching image source breakpoints to design breakpoints</h2>
+ <p>Web authors would like to be able to optionally match the breakpoints for images to the breakpoints that they have defined in their responsive designs. Being able to match the breakpoints ensures that images are operating under the same rules that define the layout. It also helps authors verify their approach by ensuring that the same viewport measurement tests are being used in both HTML and CSS.</p>
+ <p>This desire is a facet of the two preceding use cases (mobile/desktop-first responsive design and relative units). If a breakpoint in the design is defined as:</p>
+ <p><code>@media screen (max-width: 41em) {}</code></p>
+ <p>Then web authors 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 authors.</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 author would need to specify 657 pixels as a minimum width for the breakpoint.</li>
+ </ul>
+ <p>When debugging a document, if the author cannot specify breakpoints for images in the same manner that they are defined for the design, authors 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 that math errors on the part of authors (possibly due to a different rounding scheme in a particular user agent) cause unexpected behavior.</p>
+ </section>
+ <section>
+ <h2 class="informative-subhed">Mobile Networks</h2>
+ <p>It should be noted that many devices are used on mobile networks which are often very slow or exhibit high latency. Often times conferences suffer from slow networks as well due to many users attempting to use a single network connection simultaneously. Many people also have very slow or erratic connections in their homes and workplaces. While it may not be possible for a solution to be based on bandwidth, anything that can be done to reduce latency and HTTP requests should be done.</p>
+ <p>Allowing authors to specify different images for different viewport sizes and display densities is one step towards providing a better experience on slow networks. In the future, user agents may be able to select different images based on network speed or user preference.</p>
+ </section>
+ <section>
+ <h2 class="informative-subhed">User Zoom</h2>
+ <p>Images blur when the user resizes the page. Users may zoom an image in order to see more detail. In these cases, user agents could select a higher-resolution version of an image to display.</p>
+ <div class="issue">It's not clear whether the picture element is prescriptive (i.e. the user agent MUST show a particular image given certain device properties) or suggestive (i.e. the user agent has control over picking the best image).</div>
+ </section>
+ <section>
+ <h2 class="informative-subhed">Art Direction</h2>
+ <p>Web authors often want to provide different versions of the same image at different sizes depending on the viewport. We refer to this as the <dfn>a rt direction</dfn> use case.</p>
+ <p>A simple example of this would be changing the crop of an image based on display area:</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 device, 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>Examples: <a href="http://blog.cloudfour.com/a-framework-for-discussing-responsive-images-solutions/#artdirection">Large photo of Obama at a Chrysler plant vs. tighter cropped thumbnail</a></p>
+ <p>A more complex example that changes orientation of the image, crop, and how text flows around an image based on the size of the viewport:</p>
+ <ul>
+ <li>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 img to vertical made more sense because it allowed the reader to still make out the features of the browser in the image.</li>
+ </ul>
+ </section>
+ <section>
+ <h2 class="informative-subhed">Alternate Print Sources</h2>
+ <p>Printed web documents generally have pixelated images due to printers having a higher DPI than most images currently served on the web. Defining higher resolution images for printing would increase the abilities of web authors to define great 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 class="informative-subhed">Gray Scale and High Contrast Modes</h2>
+ <p>Displaying a color image on a monochrome display does not always work well, as two different colors of similar luminosity would be impossible to distinguish in a monochrome environment.</p>
+ <p>Microsoft is proposing a media query which lets you <a href="http://msdn.microsoft.com/en-us/library/windows/apps/hh465764.aspx">detect that the user agent has been put in high contrast mode</a> (for accessibility reasons), and that the content should follow along. Being able to switch images based on high contrast mode would be nice.</p>
+ <p>Extracted from <a href="http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-August/036845.html">WhatWG mailing list thread</a>.</p>
+ </section>
+</section>
-<section id="polyfills" class="appendix informative"></section>
-<!-- polyfills -->
-
+<!-- appendix -->
<section class='appendix'>
- <h1>Open Issues</h1>
- <p>...</p>
-
+ <h1>Open Issues</h1>
+ <p>We are tracking <dfn>open issues</dfn> on Github. <a href="https://github.com/Wilto/draft-prop/issues">Please help close them</a>! </p>
+ <div id="open-issues-xhr"></div>
+ <h1>Reference implementations</h1>
+ <p>We have a list of <a href="https://github.com/Wilto/draft-prop/wiki/Current-users,-polyfills,-prototypes,-and-implementations">current users, polyfills, prototypes, and implementations</a> on Github. </p>
<h1>Acknowledgements</h1>
- <p>TODO: add thanks</p>
- </section>
-<!-- appendix -->
+ <p>TODO: add thanks</p>
+</section>
+<script>
+function processResponse(obj) {
+ var issue, issues = obj.data, issues_html = '<li>No issues are open. Yay!</li>';
+ if(issues.errors){
+ console.warn("There was a problem getting the issues from github: " + issues.message, issues.errors)
+ return;
+ }
+ if(issues && issues.length > 0){
+ for (var i = 0, issues_html = ''; i < issues.length; i++) {
+ issue = issues[i];
+ issues_html += '<li><a href="' + issue['html_url'] + '">Issue ' + issue['number'] + '</a> - ' + issue['title']+ '</li>';
+ }
+ }
+ issues_html = '<ul>' + issues_html + '</ul>';
+ document.getElementById('open-issues-xhr').innerHTML = issues_html;
+}
+</script>
+<script src="https://api.github.com/repos/Wilto/draft-prop/issues?state=open&callback=processResponse"></script>
</body>
</html>
\ No newline at end of file