diff --git a/ResponsiveImages.html b/ResponsiveImages.html index 9802953f..51d19572 100644 --- a/ResponsiveImages.html +++ b/ResponsiveImages.html @@ -1,11 +1,10 @@ - HTML Responsive Images Extension - - - - + - - - - - - -
-

Through the introduction of a picture 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.

-
- -
-

This document was proposed by the Responsive Images Community Group as a solution to bug 18384.

-
- -
-

This specification describes the conformance criteria for user agents (relevant to implementors) and documents (relevant to authors and authoring tool implementors).

-

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]].

+ + + +
+

Through the combination of a new picture element and a new the srcset attribute for the existing source 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.

+
+
+

This document was proposed by the Responsive Images Community Group as a solution to bug 18384.

+
+
+

This specification describes the conformance criteria for user agents (relevant to implementors) and documents (relevant to authors and authoring tool implementors).

+

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]].

+
-

Definitions

-

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.

-

The follow terms are defined by the [[!HTML5]] specification: img element, - source element, - media resource, - resource selection algorithm, - fallback content, - valid non-empty URL potentially surrounded by spaces - and valid media query.

-

The term media type is defined by the Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types specification [[!RFC2046]].

- -

The image-set notation - microsyntax is defined by the CSS Image Values and Replaced Content Module Level 4 Specification [[!CSS4-IMAGES]].

-

The techniques for providing useful text alternatives for img elements are defined by the HTML5: Techniques for providing useful text alternatives Specification [[!ALT-TECHNIQUES]].

- -
- +

Definitions

+

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.

+

The follow terms are defined by the [[!HTML5]] specification: img element, source element, media resource, fallback content, valid non-empty URL potentially surrounded by spaces and valid media query.

+

The image-set notation microsyntax is defined by the CSS Image Values and Replaced Content Module Level 4 Specification [[!CSS4-IMAGES]].

+

The techniques for providing useful text alternatives for img elements are defined by the HTML5: Techniques for providing useful text alternatives Specification [[!ALT-TECHNIQUES]].

+
-

The picture element

-
+

The picture element

+
Categories:
Flow content.
Phrasing content.
Embedded content.
-
Palpable content.
+
If the element has a usemap attribute: Interactive content.
Contexts in which this element can be used:
Where embedded content is expected.
Content model:
If zero descendents, then transparent.
-
One or more source elements.
- - -
Zero or one img element as fallback content.
+
Zero or one img element, serving as fallback content.
Content attributes:
Global attributes
- +
crossorigin
+
usemap
+
ismap
+
width
+
height
DOM interface:
-
Uses HTMLElement (this will change as we start working on events!).
+
Uses HTMLImageElement.
- - -

The picture element used for displaying an image that can come from a range of sources. Which image the user agent displays depends on [forthcoming algorithm].

-

For user agents that don't support the picture element, an author can provide an img element as fallback content. User agents SHOULD NOT show this content to the user: it is intended for legacy user agents that do not support picture, so that a legacy img element can be shown instead.

-

Authoring requirement: as with the img element, the picture element must not be used 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.

-

Example of usage

-

Sample picture element markup:

- -
<picture>
+  
The picture element used for displaying an image that can come from a range of sources (see srcset attribute). Which image the user agent displays depends on the 
+        algoithm for deriving the source image. 

+  
The chosen image is the embedded content.      

+      
The crossorigin attribute is a CORS settings attribute. Its purpose is to allow images from third-party sites that allow cross-origin access to be used with canvas.

+      
The width and height attributes represent the dimensions of the visual content of the element (the width and height respectively, relative to the nominal direction of the output medium), in CSS pixels. They are in everyway the same as those of an img element. The value of attributes, if specified, are valid non-negative integers.

+      
For user agents that don't support the picture element, an author can provide an img element as fallback content. User agents SHOULD NOT show this content to the user: it is intended for legacy user agents that do not support picture, so that a legacy img element can be shown instead.

+      
Authoring requirement: as with the img element, documents  must not use the picture 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.      

+      
Example of usage

+      
Sample picture element markup:

+      
<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="">
-</picture>

-	
-  

-    
Differences from img element

-	  
Unlike the img element, which is limited to pointing to a single image resource, the picture element is intended to allow an author to reference many different image sources that the browser can then choose based on a media query or some other relevant condition. 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: art direction use case). 

-	  
It is also not possible to assign a source directly to a picture element. For that case, an author needs to use an img element instead. 

-  

+   <p>Accessible text</p>
+</picture>
+
+

Differences from img element

+

Unlike the img element, which is limited to pointing to a single image resource, the picture element is intended to allow an author to reference many different image sources that the browser can then choose based on a media query or some other relevant browsing situation or contraint. 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: art direction use case).

+

It is RECOMMENDED that for cases where a single image source is available, and where no responsive adaption is needed, authors use the img element.

+
+ + +
+

When used with the picture element, a document SHOULD only contain source elements need to represent the same subject matter, but cropping and zooming can differ.

+
It should be codified that this is not a mechanism by which to swap disparate images depending on screen size. See bug 18384.
+
+ + + + -
- -

When used with the picture element, a document SHOULD only contain source elements need to represent the same subject matter, while cropping and zooming can differ.

-
It should be codified that this is not a mechanism by which to swap disparate images depending on screen size. See bug 18384.
-
-
-

The srcset attribute

-

The srcset attribute of the source element is is used to refer to alternate media resources for a single image at different resolutions. The expected value of the attribute is a comma-separated list of valid non-empty URL potentially surrounded by spaces that makes use of the image-set notation micosyntax.

-
- +
+

The srcset attribute

+

The srcset attribute of the source element is is used to refer to alternate media resources for a single image at different resolutions. The expected value of the attribute is a comma-separated list of valid non-empty URL potentially surrounded by spaces that matches the valid-srcset production:

+ 
valid-srcset = [ <image-set-decl>, ]* [ <image-set-decl> | <color>] ) 
+<image-set-decl> = [ <image> | <string> ] <resolution>
+

 

+
- -
-

Algorithms

-

Editorial note: goals for the algorithm

- - -

The basic algorithm for processing the picture element is as follows:

+
+

Algorithm for deriving the source image

+

The algoithm for deriving the source image as follows. The result is the image source to be used by the picture element, which reflects the picture element's src IDL attribute:

+
+

What we want to do is have the picture behave exactly the same as an img element, but with the only difference being that it is source elements is used to determine the value of the src IDL attribute (and hence what image content is displayed). How that is determined is through using the media attribute attribute of the source element.

+

To avoid complexity, the type attribute is all child source elements is ignored in this context.

+

So, to derive the source image: we gather all the media queries from the source elements' media attributes into a "stylesheet", in document order. Any missing media attributes are just assumed to mean "all". Any media attributes that are not valid media queries are ignored. So, given the following:

+
<picture id="pictureElement">
+   <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">
+   
+   <!-- assume media all --> 
+ 	<source srcset="small-1.jpg 1x, small-2.jpg 2x">
+   
+   <!-- the following are ignored -->
+   <source media=" is the massage " srcset="">
+      
+</picture>
+

Becomes the rough CSS equivelent of (a virtual stylesheet for the document?):

+
 
-		
    
-			
  1. Evaluate media/src/srcset attributes on the parent picture element first.
-				
    See http://lists.w3.org/Archives/Public/public-html/2012Jun/0116.html
    
-				
      
-					
    1. If the media attribute on the picture element should match, evaluate srcset ( per the image-set notation algorithm ) or the src attribute.
      2. 
-					
    2. If not, continue to step two below.
      3. 
-				
    
-			
    2. 
-			
  2. Evaluate source child elements per the resource selection algorithm already defined for the media attribute to select the appropriate source element.
    3. 
-			
  3. Once the source element has been identified, look to see if the element has srcset defined. If srcset exists, follow the the image-set notation algorithm. If src is specified on the source element, let that be the chosen picture source.
    4. 
-			
  4. The user agent will ignore any img elements that are children of the picture element.
    5. 
-		

-		
It should be possible to determine from script which source was selected. For media elements, this is done with the currentSrc IDL attribute.

-
+//assume #pictureElement is magically scoped to the correspoding element. +@media all{ + #pictureElement{ + background-image: image-set(small-1.jpg 1x, small-2.jpg 2x); + } +} -
- +@media all and (min-width: 45em){ + #pictureElement{ + background-image: image-set(large-1.jpg 1x, large-2.jpg 2x); + } +} -
-

Accessibility

-

The picture element relies on fallback content as representative alternate text, rather than calling for an alt attribute on both the parent picture element and the fallback img. This provides a method for specifying short alternative text without requiring authors to specify an identical attribute on both picture and the fallback img, with the potential to reach the greatest number of end users without requiring a redundant effort on the part of authors.

- - The alt attribute MUST be handled according to the techniques for providing useful text alternatives for img elements no different from alt attributes on img elements outside of the picture context.

-

The alt attribute is NOT permissible on source elements. If the alternate text description of a source element differs from other source elements, it would suggest that the listed sources are not different versions of the same image, but are likely to be different images entirely.

-
-

The eventual resolution of ISSUE-30: Should HTML 5 include a longdesc attribute for images will determine the method by which authors can provide semantically rich markup as accessible text.

-

Further accessibility discussion can be viewed at http://lists.w3.org/Archives/Public/public-html/2012Sep/0029.html.

-
-
+@media all and (min-width: 18em){ + #pictureElement{ + background-image: image-set(med-1.jpg 1x, med-2.jpg 2x); + } +} +

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.

+

The resource fetching behavior of then governed by CSS Image Values and Replaced Content Module Level 4.

+ -
-

Examples

-

TODO: add examples

-
-
-
-

Goals

-

This proposal was designed with the following goals in mind:

-
    -
  • Respond to different screen pixel width/height.
    • -
  • Respond to different screen pixel densities.
    • -
  • Respond to user zoom on image resource.
    • -
  • Provide user agents with information they need to select the most appropriate image source given low bandwidth situations.
    • -
  • Will fallback gracefully on older user agents.
    • -
  • Can be polyfilled effectively.
    • -
  • Retains, at a minimum, the same level of accessibility as current img element.
    • -
  • Preserves separation of content markup and styling.
    • -
  • Provides a purely client-side solution which can include JavaScript, but doesn’t require it.
    • -
  • Supports use cases where authors need to explicitly define different image versions as opposed to simply different resolutions of the same image.
    • -
  • Provides a consistent and predictable pattern for delivering alternate media sources based on client context.
    • -
  • Supports succinct but understandable mark-up.
    • -
  • 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
    • -
-
-

Use Cases

-

There are many use cases that are supported as listed below. There are two primary use cases:

-
    -
  1. The need for different image sources at different viewport sizes in responsive web designs.
    2. -
  2. The need for different image sources depending on the pixel density of the display.
    3. -
-

Most of the more specific use cases fall under one of these two umbrella needs.

- -

Viewport Sizes

-

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.

-

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.

-

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.

-

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.

-

Display Density

-

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.

+

A user agent may be able to 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.

-

We should be ready and able to support the current resolutions as well as any others that manufacturers may use in the future.

+
+ -

Mobile-first and desktop-first responsive design

-

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.

-

“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.

- -

These two approaches require that a solution for images support the following:

- -

Relative Units

-

A common practice in creating flexible layouts is to specify the size values in media queries as relative units: em, rem, vw/vh 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.

- -

Matching image source breakpoints to design breakpoints

-

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.

- -

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:

- -

@media screen (max-width: 41em) {}

- -

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:

- - - -

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.

- -

Mobile Networks

-

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.

+
+

Examples

+

TODO: add examples

+
+ -

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.

- -

User Zoom

-

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.

-
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).
- -

Art Direction

-

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 a rt direction use case.

-

A simple example of this would be changing the crop of an image based on display area:

- -

Examples: Large photo of Obama at a Chrysler plant vs. tighter cropped thumbnail

-

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:

- - -

Alternate Print Sources

-

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.

- -

Gray Scale and High Contrast Modes

-

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.

-

Microsoft is proposing a media query which lets you detect that the user agent has been put in high contrast mode (for accessibility reasons), and that the content should follow along [http://msdn.microsoft.com/en-us/library/windows/apps/hh465764.aspx]. Being able to switch images based on high contrast mode would be nice.

-

Extracted from WhatWG mailing list thread.

-
- - -
-

Pre-existing Polyfills

- -
+
+
+

Goals

+

This proposal was designed with the following goals in mind:

+ +
+

Use Cases

+

There are many use cases that are supported as listed below. There are two primary use cases:

+
    +
  1. The need for different image sources at different viewport sizes in responsive web designs.
    2. +
  2. The need for different image sources depending on the pixel density of the display.
    3. +
+

Most of the more specific use cases fall under one of these two umbrella needs.

+

Viewport Sizes

+

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.

+

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.

+

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.

+

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.

+

Display Density

+

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.

+

We should be ready and able to support the current resolutions as well as any others that manufacturers may use in the future.

+

Mobile-first and desktop-first responsive design

+

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.

+

“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.

+

These two approaches require that a solution for images support the following:

+ +

Relative Units

+

A common practice in creating flexible layouts is to specify the size values in media queries as relative units: em, rem, vw/vh 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.

+

Matching image source breakpoints to design breakpoints

+

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.

+

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:

+

@media screen (max-width: 41em) {}

+

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:

+ +

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.

+

Mobile Networks

+

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.

+

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.

+

User Zoom

+

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.

+
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).
+

Art Direction

+

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 a rt direction use case.

+

A simple example of this would be changing the crop of an image based on display area:

+ +

Examples: Large photo of Obama at a Chrysler plant vs. tighter cropped thumbnail

+

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:

+ +

Alternate Print Sources

+

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.

+

Gray Scale and High Contrast Modes

+

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.

+

Microsoft is proposing a media query which lets you detect that the user agent has been put in high contrast mode (for accessibility reasons), and that the content should follow along. Being able to switch images based on high contrast mode would be nice.

+

Extracted from WhatWG mailing list thread.

+
+ -
-

Acknowledgements

-

TODO: add thanks

-
+
+

Pre-existing Polyfills

+ +
+ - +
+

Acknowledgements

+

TODO: add thanks

+
+ \ No newline at end of file