Bug 116963 - (picture) Implement `picture` element
(picture)
: Implement `picture` element
Status: UNCONFIRMED
: WebKit
HTML DOM
: 528+ (Nightly build)
: All All
: P2 Normal
Assigned To:
: http://www.w3.org/TR/html-picture-ele...
:
:
:
  Show dependency treegraph
 
Reported: 2013-05-29 07:46 PST by
Modified: 2014-03-03 00:26 PST (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2013-05-29 07:46:41 PST
The `picture` element is a markup pattern that allows developers to declare multiple sources for an image using `media` attributes on `source` elements, similar to the `video` element. This allows authors to specify requirements for when/if image sources are requested/displayed.

The Specification published by the HTML WG is the following:
http://www.w3.org/TR/html-picture-element/

Note that the `picture` element is able to make use of the resolution feature of the `srcset` attribute, but does not strictly require it. The two patterns are complementary, and together fulfill the full list of Use Cases and Requirements for Standardizing Responsive Images as published by the W3C:
http://www.w3.org/TR/2013/WD-respimg-usecases-20130226/

Change description:
Enable a responsive images solution and give developers control over the image resource that is downloaded & displayed using the various resources' media attributes

Changes to API surface:
* The `picture` element will be recognized in HTML and displayed as an image. 
* Its `src` attribute will trigger a resource download. 
* The `src` attribute of the first matching `source` child element with a matching `media` attribute will trigger a resource download, unless `picture`has an `src` attribute.
* The DOM API for the element will resemble that of `img`, with possible minor changes.

Public standards discussion: http://www.w3.org/TR/html-picture-element/

---

Additional information about this:

We ran an open survey, and 42% of the 264 responses (at time of posting this) said that they are making use of “art direction” with their current “responsive images” solution.
This survey is largely comprised of attendees of last week’s Mobilism conference and developers following http://twitter.com/smashingmag (702,117 followers), so I assume it represents a fairly wide cross-section of the developer community. It’s also worth noting that developers heavily favor the `picture` element (or equivalent polyfill).
https://docs.google.com/forms/d/1LIbd9wiM7M_m-rUB85WAiGT-h8QUY-PRJwjiBRiuY4Y/viewanalytics
------- Comment #1 From 2014-01-11 05:49:23 PST -------
The specification had recently undergone a significant simplification. The latest version can be found in http://picture.responsiveimages.org/

As a result, the above change description is no longer accurate.

A better description of current proposed API surface change:
* The `srcset` attribute will be extended. It would be able include resource dimensions, as an alternative to DPR.
* The `sizes` attribute will be defined, enabling the browser to calculate the appropriately sized resource needed, before layout is calculated.
* The `<picture>` element will be defined and used (with its child `<source>` elements) for the child `<img>`'s resource selection.

According to the new specification, `<img>` remains responsible for displaying the actual image, so previous concerns regarding `<picture>` requiring duplication of img's layout tests were addressed.


Is the WebKit project interested in accepting patches for this feature?

Thanks,
Yoav

P.S. CCing Maciej since he reviewed the spec on WHATWG