TAG Recommenations to the RICG
On the 31st of May, Marcos Cáceres gave an overview to the TAG members of the challenges being faced by the Responsive Images Community Group (RICG).
Over the last two years, the RICG has been trying to solve the problem of "responsive images": given a set of environmental and device constraints (network type, device dimensions and pixel ratio), the user agent should select an image most appropriate to present to an end-user. This work grew out of much real-world experimentation within the Web Development community to try to solve this problem with various hacks and polyfills (see  for an overview of techniques currently used in the wild and pros and cons of each approach). Given the limitations and issues with the techniques found in , the Web development community got organized to try to work with browser makers to come up with a "in browser" solution.
To inform the standardization process, the RICG produced a set of use cases and
requirements  and is working on a specification for a new
destined for the HTML specification . In parallel, as a response to the
demand for a solution from the RICG the WHATWG introduced a new attribute on the
img element called
srcset . As
srcset did not adequately meet the
RICG's use cases, the
picture element builds on
srcset to meet the goals
Although this work has been going on for over a year, there has been little
traction from browser makers with regards to implementing either
srcset. This has effectively paralyzed work on these specifications and left
the RICG in a state of dissolution. The RICG reached out to the TAG for guidance
on how to proceed forward.
The TAG recommends that the RICG continue to formalize and popularize polyfills that meet their use cases, like Picturefill (and not wait for browser makers to implement their specification). Reaching critical mass with polyfills should help convince browser makers that a solution should indeed be standardized for the benefit of end-users, even if it takes a few more years.
The TAG recommends that the RICG discourage developers from directly using the
srcseton the Web before the solution is standardized and widely available in browsers. This is to avoid compatibility conflicts if browser start to implement
<picture>in the future. If browsers do end up exposing srcset, they should only do so behind a user settable flag (not a vendor prefix!) until there is wide consensus that that is the right solution for the Web platform.
The TAG recommends polyfilling a solution based on Web Components and encourages the RICG to reach out to high profile polyfill implementations (e.g., x-tags and polymer) to have their solution integrated into those libraries. This should assist with the proliferation of responsive images solutions in the medium term.
Given 1 and 3, the RICG should continue to monitor usage of the solutions in the wild and continue to refine their specification based on that. Experimentation is critical to the refinement of a solution (see http://extensiblewebmanifesto.org/).