WebKitのナイトリビルドが，W3Cのimageエレメントでsrcset属性仕様をサポートした。高解像度ディスプレイを所有するユーザに対して，それ以外のユーザに不利益を与えることなく，高品質のイメージを提供することが可能になる。この機能をサポートしていないブラウザに対しても，適切なフォールバックが用意されている。
<img alt="My breakfast" src="breakfast.jpeg" srcset="breakfast-HD.jpeg 2x, breakfast-phone.jpeg 100w, breakfast-phone-HD.jpeg 100w 2x">
WebKitではすでに以前から，srcsetに非常によく似た-webkit-image-setというCSS関数がサポートされていた。イメージを参照するCSSプロパティに対して，"2x"のような修飾子付きの候補イメージURLのリストを指定することが可能だ。ブラウザはこれを使って，ユーザのデバイスに最適なイメージを選択する。
body {
background: -webkit-image-set( url('path/to/image') 1x, url('path/to/high-res-image') 2x );
}
WebKitでこの機能が実現した一方で，コミュニティやブラウザ実装者たちの間では，Webでレスポンシブイメージ(Responsive Image)を扱うための最善策は何か，いまだ意見の分かれている状態だ。数週間の内にRICG(Responsive Images Community Group)がパリで開催されて，レスポンシブイメージに関する方針が話し合われることになっている。会議への参加を呼び掛けたRICGのYoav Weiss氏は，その中で将来的に考えられるソリューションと，現在の開発状況の概要を次のようにまとめている：
Web開発者は，レスポンシブイメージに強い関心を持っています。レスポンシブイメージをWebに導入する方法を見つけるために，この数年間，多くの人たちが試行錯誤を続けてきました。現時点で３つのプロポーザル(srcset[1], <picture>[2], client-hints[3])が提出されていますが，いずれのソリューションがもっとも効果的にユースケースを満足するのかを市場で決定する上で，ブラウザ実装者の間に十分な機運が起きているとはいい難い状況です。
それまでの間，Web開発者は特別なポリフィル(Polyfill，埋め合わせ)を用意せざるを得なくなりますが，この方法は往々にして，ブラウザにDOMが(少なくとも部分的に)ロードされてページ上のJavaScriptが起動するまで，イメージリソースの読み込みが遅延する，という状況を生み出します。これはブラウザ開発者が長年培ってきた努力，すなわちリソース読み込みの最適化や，送信されたリクエストをプライオリティに従って可能な限り早く取得する，などのパフォーマンス向上策を直接的に阻害するものです。結果として開発者にはジレンマが残ることになります。"イメージ読み込み処理が遅くなったのか，それとも，余分なイメージをダウンロードしてロード時間全体が長くなったり，不要な課金を発生させたりしているのだろうか？"
レスポンシブイメージをWebで実現する方法として，現時点で一般的なのは次のようなものだ：
- Picturefill: 提案中の <picture>エレメントを模擬するポリフィル
- HiSRC: ページ読み込み時，デバイスのサポート有無に従って高解像度イメージを選択する(あるいは選択しない)jQueryプラグイン
- Adaptive Images: 適切な解像度およびサイズのイメージを提供する，サーバサイドソリューション