次世代HTMLの新仕様「レスポンシブ・イメージ（仮）」についてまとめてみた

更新日 2017年11月23日

レスポンシブWebデザインを実装する際、画像の扱いは一つの課題として残っています。現在、PHPを使用した「Adaptive Images」やJavaScriptを使った「Responsive-Images」などが現実的な対応策としてありますが、どちらもApacheの設定を必要とします。レスポンシブWebデザインが広まって標準的な実装方法の一つになろうとしている今、サーバサイド技術に依存しない解決策が早急に求められています。

そんな中、HTMLの仕様策定の一端を担うWHATWG（Web Hypertext Application Technology Working Group – ワットダブルジーと読む）で、新たな仕様が検討されています。

では、どんな議論がされていて、今どんな状況なのか？
なかなか複雑なことになっているようなので、調べてまとめてみました。

※この記事は、レスポンシブWebデザインを実装する際の画像の扱い方法をまとめたものではなく、将来HTML/CSSに追加される可能性のある仕様についてまとめたものです。現段階では、残念ながら特に解決策などは出ていません。

1. 2つの候補 — <picture>とsrcset属性

HTMLの仕様策定には、現在HTML WG（HTML Working Grouop）とWHATWGという2つのグループが関わっているのですが、その一つWHATWGで候補にあげられ議論されている仕様が2つあります。

候補1. <picture>

ウェブ制作・開発者の支持を集めている仕様。

候補2. srcset属性

WHATWGの運営メンバーとブラウザ・ベンダーの支持を集めている仕様。

これらの議論が進む中、5月に突然、WHATWGの運営メンバーでありHTML5のエディターでもあるIan Hickson氏（現在Google勤務）が、srcsetをWHATWGの仕様草案に入れたことを発表。開発者コミュニティーを驚かせ、というか激怒させているようです。

その後、<picture>とsrcset属性のハイブリッド版がOperaの開発者であるFlorian氏から提案され、その提案をもとにResponsive Images Community Groupが「Picture Element Proposal」（6月29日？またはつい最近）をまとめ、HTML WGにHTML.nextの一部として、また、WHAT WGにも提案として提出し現在（6月30日）に至っています。

-webkit-image-set()

また、この動きとは別にRetina対応を施したいAppleが、Webkit向けにprefix付きでimage-set()という機能を実装すると発表。これはRetinaディスプレイのようにデバイスピクセル比が違うスクリーン向けに、個別の画像を指定できる「パッチ」で、7月に発売を控えているMountain Lionに搭載されるSafari 6、iOS6のMobile Safariに実装されるとのことです。

日本でもレスポンシブWebデザインが広まりはじめている昨今、WHATWGには公平にかつ迅速にレスポンシブ・イメージに対応して貰いたいところです。

参考

2. HTMLとCSSの仕様決定のプロセス

では、いったいHTMLやCSSの仕様はどのように決められているのか？
大まかには以下のようなプロセスを踏んでいます。

W3Cの仕様は、憲章（Charter）で定めたワーキング・グループ（Working Group）が起草し、ディレクターの承認を得た案が以下のプロセスを経て正式に標準の仕様として認められます。

草案
最終草案
勧告候補
勧告案
W3C勧告

通常、このプロセスに年単位の時間がかかっているようです。

HTMLの仕様

現在、HTMLはW3C HTML WGとWHAT WGが策定しています。

このW3C HTML WGとWHAT WGにはちょっとした「過去」があって、もともとW3CがHTMLを放ったらかしにしてXHTMLに専念していたところ、HTMLの将来を危惧したメンバーがWHATWGを立ち上げました。現在、Ian Hickson氏がHTML WGとWHATWGの両方のエディターで、他のメンバーも両方参加している方が多いそうです。

現在、WHATWGは“living standard”という彼らの仕様を作っており、HTML WGはそこから”snapshots”として仕様をHTML5に入れるというプロセスを踏んでいるようです。ちなみに、HTML5は~~2012年~~2014年（間違ってました！）に最終勧告に至ると言われています。

CSSの仕様

CSSはHTMLとは別のワーキング・グループのW3C CSS working groupが維持をしています。6月19日に発表されたMedia Queriesの正式ウェブ標準化は、このグループから発表されています。

余談になりますが、HTML5 Japanese Interest Groupという日本語でHTML5について議論するグループもあるんですね。レスポンシブ・イメージに関する彼らの見解も伺ってみたいですね。

参考

3. ブラウザ・ベンダー vs ウェブ制作・開発者

今回のゴタゴタで、主要メンバーがブラウザ・ベンダーの開発者からなるWHATWGの運営側と、ウェブ制作・開発者からなるWHATWGコミュニティーの、あまり良くない関係が浮き彫りになりました。ある意味、対立関係にまで発展しそうな勢いを見せています。WHATWGコミュニティーが最善の手法を議論しているさなかに、コミュニティーの支持をあまり得ていないsrcset属性がWHATWGの仕様草案に入れ込まれたからです。どんな理由があったにせよ、このIan Hickson氏の行動には大きな疑問が残ります。

モバイル技術が進化しスマホやタブレット端末の普及が急速に進み、レスポンシブWebデザインという手法を使って多くのウェブサイトが制作され始めています。そして、レスポンシブ・イメージの課題が迅速に解決されることを多くのウェブ制作・開発者が望んでいます。ベンダー側、制作側の双方の歩み寄りで、ある特定のグループだけでなくウェブ全体、そしてユーザのメリットになるような仕様を迅速に決めてもらいたいと願うばかりです。

4. レスポンシブWebデザインで使うイメージの課題

「レスポンシブ・イメージ」の仕様策定に関する動きは、僕が調べてみた限り先述したような状況になっています。では、具体的にレスポンシブ・イメージの課題はどういったものなのでしょうか？自分でレスポンシブWebデザインのウェブサイトを運営してみて実感していること、また、「レスポンシブ・イメージ」関連の議論を読んてみて思ったことを整理してみると、それらは以下の3つにまとまります。

スクリーンサイズにあった画像を提供したい
デバイスピクセル比にあった画像を提供したい
回線速度にあった画像を提供したいしたい

1. スクリーンサイズにあった画像を提供したい

「Fluid Image（フルーイッド・イメージ）」と呼ばれる手法で、画像を100%幅で表示させることである程度の対応ができますが、あらゆる状況に「最適」といえる対応ではありません。たとえば、900px幅の画像を、320px幅のスマホ・スクリーンでそのまま表示させると画像が小さくなってしまうため、どうしても調整が必要になります。また、デスクトップ向けに小さ目に表示していた画像をスマホやタブレットで100%幅で表示すると、画像が拡大されて粗く見えてしまいます。

また、以下のようにスクリーンサイズによって画像の大きさを変えるだけでなく、クロッピングなどの見せ方も変えたい場合もあります。これも、ファイルサイズなどを考慮するとJavaScriptかサーバサイドの技術を使うしか選択肢がありません。

デスクトップでの表示：

これを100%幅にして幅320pxのスマホで表示させると…

小さくなってインパクトに欠けてしまうので、できれば、以下のようにクロッピングも調整して表示したい

2. デバイスピクセル比にあった画像を提供したい

例えば、このブログのロゴをRetinaスクリーンのiPhone 4で見ると、画像がかなりぼやけて見えてしまいます。背景画像として指定する場合はCSSで対処できますが、<img>で画像を表示する場合サーバーサイド技術やJavaScriptを使って写真を入れ替える必要があります。以下は背景画像がぼやけてしまう例ですが、<img>の画像表示でも同じ問題に直面します。

デスクトップで見た場合：

iPhone 4で見た場合：

※上記のようなロゴの場合、ロゴやアイコンをフォントにして表示する「アイコンフォント」という手法を使って対応することも考えられますが、その手法自体にも課題が残っていそうです。WebサイトのRetina対応についてまとめているブログ記事もありました。

デバイスピクセル比やピクセル密度については「スマートフォンと画面解像度・ピクセル密度」という記事で詳しく説明されています。

3. 回線速度にあった画像を提供したい

たとえば、3G回線でウェブサイトを見ている場合はクオリティや解像度を下げた画像を、逆にブロードバンド回線の場合はクオリティが高く解像度もスクリーンに最適なものを提供できるのが望ましいです。また、Retinaディスプレイを搭載したiPadやiPhoneのようなデバイスでは、デバイスピクセル比と回線速度のコンビネーションで、提供する画像を選択できるのが望ましいです。

しかし、Media Queriesでは回線速度までは判別できません。また、ブラウザにも回線速度を判別するような機能は設けられていないので、現状ユーザがどのような回線環境でウェブサイトを閲覧しているか判別することはできません。解像度で判別してスクリーンサイズごとに違う画像を提供できれば、ある程度は回線速度の問題も改善できそうですが、Retina対応を考慮すると課題として残ってしまいます。

2つの仕様候補の詳細

今度は、提案されている候補のうち最も有力な二つの仕様の詳細を見てみます。

1. <picture>

誰が提案して誰に支持されているのか

数ヶ月の議論の結果、W3CのResponsive Images Communityから「Adaptive Images」と題してWHATWGに提案がされました。WHATWGのコミュニティメンバーであるウェブ制作・開発者に支持されているようです。

概要

<video>や<audio>タグのパターンを利用したフォーマットで、メディアクエリを<source>内に属性として指定して、デバイスのスクリーンサイズごとに表示する画像を選べるようにする。

サンプルコード

<picture alt="a picture of something">
<!-- Matches by default: -->
<source src="mobile.jpg" />
<source src="medium.jpg" media="min-width: 600px" />
<source src="fullsize.jpg" media="min-width: 900px" />
<img src="mobile.jpg" /><!-- fallback for non-supporting browsers -->
</picture>

media属性にMedia Queriesで使用するスクリーンサイズの指定をする
<picture>をサポートしないブラウザ向けに<img>タグを入れる

解決できる課題

○	スクリーンサイズにあった画像を提供したい
×	デバイスピクセル比にあった画像を提供したい
×	回線速度にあった画像を提供したいしたい

考えられる問題点

1つのイメージに対してコードが冗長で書くのが大変
イメージ毎にこの設定をしなくてはならない
デザイン要素と文書データが混同してしまう。たとえば、CSSだけでデザイン・レイアウトの変更をするリニューアルができない

2. srcset属性

誰が提案して誰に支持されているのか

AppleのEdward O’Conner氏がWHATWGに提案したが、WHATWGコミュニティではあまり支持されなかった。

概要

<img>の属性として、画像ソースを複数指定する方法

サンプルコード

<img alt="image description" src="/path/to/fallbackimage.png" srcset="/path/to/image.png 800w, /path/to/otherimage.png 600w">

src属性がデフォルトの画像
srcset属性でスクリーンサイズごとの画像を指定する。800w = 幅800px

解決できる課題

○	スクリーンサイズにあった画像を提供したい
×	デバイスピクセル比にあった画像を提供したい
×	回線速度にあった画像を提供したいしたい

考えられる問題点

Syntaxが慣れないもので分かりにくい
min-widthなのかmax-widthか指定されていない
幅がpx指定しか考慮されていない
<picture>と同様にデザイン要素と文書データが混同してしまう

3. ハイブリッド

誰が提案して誰に支持されているのか

原案はOperaの開発者でMedia QueriesのエディターでもあるFlorian Rivoal氏によって提案されました（2012年5月23日）。それを基にResponsive Images Community GroupのChairであるMat Marquis氏が「Picture Element Proposal」をHTML WGにHTML.nextの一部として、また、WHATWGにも提出しました（6月29日？）。

概要

<picture>とsrcset属性のいいとこ取りで考えられた案。<picture>にsrcset属性が組み込まれた形をとっている。また、JavaScriptでこの仕様をシミュレートする「Picturefill」というPolyfillも用意されていて、この仕様をサポートしないブラウザでは、これを使えば実装できるように準備されています。

サンプルコード

<picture>
  <source srcset="small-1.jpg 1x, small-2.jpg 2x">
  <source media="(min-width: 18em)" srcset="med-1.jpg 1x, med-2.jpg 2x">
  <source media="(min-width: 45em)" srcset="large-1.jpg 1x, large-2.jpg 2x">
  <img src="small-1.jpg">
</picture>

基本は<picture>と同じ構造
media=””には、Media Queriesを使用する。たとえばmedia=”(orientation: portrait)”なんていうのも可能
srcset=””に、画像のソースとデバイスピクセル比を指定して、Retinaなどの高解像度スクリーンに対応
フォールバックとして<img>を使用

解決できる課題

○	スクリーンサイズにあった画像を提供したい
○	デバイスピクセル比にあった画像を提供したい
×	回線速度にあった画像を提供したいしたい

考えられる問題点

1つのイメージに対してコードが冗長で書くのが大変
イメージ毎にこの設定をしなくてはならない
<picture>とsrcset属性と同様にデザイン要素と文書データが混同してしまう

回線速度の問題や上記の考えられる問題点は、提案されているどの方法を用いてもついてまわる課題です。Polyfillも用意できていますし、このハイブリッド型がいまのところ一番現実的なように思えるのですが、ブラウザ・ベンダーの方々は違う視点を持っているのでしょうか？

参考

様々な提案の詳細をまとめた記事「Responsive images: what’s the problem, and how do we fix it?」。詳細にわたる説明で、すばらしい記事です。

まとめ

レスポンシブ・イメージの課題の一つである回線速度の問題は、どの方法でも現状は解決不可能となっています。ブラウザに回線速度やCPUの情報を判別する機能を組み込めれば良いのにと思いますが、技術的な問題だけでなく、プライバシーやセキュリティの問題にも繋がる可能性があるのでしょうか？また、できたとしても、それがブラウザ標準として主要ブラウザのすべてに実装されるまでには長い年月を必要とします。

であれば、個人的には回線速度以外の課題をすべて解決できると思われるハイブリッドの方法で仕様策定を進めるのが良いと思うのですが。HTML WGとWHAT WGの動きにこれからも注目です。

A List Apartの記事で、Mat Marquis氏が「最優先とされるべきはユーザに対する明確な利益だ（our highest priority must remain providing a clear benefit to our users）」と言っていますが、まさにその通りだと思います。ブラウザ・ベンダーやウェブ制作者・開発者の都合ではなく、再度ユーザのメリットを中心に据えて考え直せば、自ずと良い解決方法は見出せると信じています。

他のレスポンシブ・イメージ関連の記事

こちらもご参考までにどうぞ：

2012年6月30日に公開され、2017年11月23日に更新された記事です。

About the author

「明日のウェブ制作に役立つアイディア」をテーマにこのブログを書いています。アメリカの大学を卒業後、ボストン近郊のウェブ制作会社に勤務。帰国後、東京のウェブ制作会社に勤務した後、ウェブ担当者として日英バイリンガルのサイト運営に携わる。詳しくはこちら。

ウェブ制作・ディレクション、ビデオを含むコンテンツ制作のお手伝い、執筆・翻訳のご依頼など、お気軽にご相談ください。いずれも日本語と英語で対応可能です。まずは、Mastodon @[email protected] 、Twitter @rriver 、またはFacebook までご連絡ください。

この記事をシェアする