要約

  • W3Cは2013年2月、Responsive Images Community Groupと協力してpicture要素の初公開草案と画像の用途を整理した草案を出した。
  • 現在のHTMLでは、srcsetとsizesが同じ構図のファイル選択を助け、pictureとsource mediaが画面に応じた構図の切り替えを担う。

写真部が選んだのは、空を広く使った海岸の写真だった。波は岩を洗い、赤い灯台が遠くで踏ん張る。机上の画面なら、余白の大きさが灯台の孤独を引き立てる。スマホに載せると話が変わる。余白はそのまま、灯台だけが探し物になる。縮小は正確でも、編集は失敗する。

ウェブページの外枠は画面幅に合わせて列や余白を変えられた。しかし、普通のimg srcに記された一つの画像URLは、広い紙面と狭い紙面に同じ写真を届ける。あとからスクリプトで差し替える手もあるが、ブラウザーはHTMLを読む途中から画像の取得を始めたい。どの写真を用意しているか、早めに知らせる仕組みが要った。

W3Cは2013年2月26日に二つの初公開作業草案を発表した。一つがpicture要素、もう一つがレスポンシブ画像の用途と要件だ。両文書はResponsive Images Community Groupと協力して作られた。撮った写真を何倍で送るかという話と、そもそも何を写した写真にするかという話が、同じ会議に持ち込まれたのである。

当時のpicture草案は、CSSのメディアクエリーに応じて画像の出所を決める容器を構想した。候補と条件をHTMLに書けば、ブラウザーはページを読みながら選択肢を把握できる。2013年の文書はまだ作業草案で、書き方の細部は流動的だった。それでも「編集者が候補を示し、ブラウザーが環境に合わせて選ぶ」という骨格は鮮明だった。

同年11月のW3Cの用途文書を読むと、問題が二種類あることが分かる。同じ構図を異なる画素数で届ける解像度の切り替え。もう一つは、狭い枠でも主役が見えるように写真を切り直すアートディレクションだ。灯台の写った遠景を高精細にすれば、よりくっきりした小さな灯台が届く。それで喜ぶのはたぶん灯台より回線の請求書だ。

WHATWGの現行HTML画像章は二つの仕事を整理している。srcsetには、画素密度を示す候補を書ける。表示幅が画面によって変わる場合は、幅を示す候補とsizesで、画像が占める予定の場所を伝える。ブラウザーはディスプレイの密度やズームなどを見ながら、与えられた資源の中から適切なファイルを選ぶ。写真部は献立を作り、ブラウザーは席の大きさを知っている。

構図を変えるならpictureと、その中のsourceを使う。sourceはmedia条件と画像候補を持てる。ブラウザーは条件に合う最初のsourceを選び、その候補から資源を決める。内側のimgは表示する画像要素として残り、代替の経路も担う。広い画面には海岸全体、狭い画面には灯台に寄った写真。切り抜きは発行前に人間が用意しておく。

構図の選択とファイルの選択は重ねられる。スマホ向けの近景にも複数の解像度を用意できるし、デスクトップ向けの遠景にもできる。まず何を見せるか、次にその画面にどのファイルを届けるか。この順番が編集の責任を明瞭にする。悪い構図を四種類の高精細ファイルに増やしても、灯台捜索隊の仕事が増えるだけだ。

imgの代替テキストも忘れられない。画像が記事で果たす役割を、画面を見ない読者に言葉で渡すためのものだ。候補写真の見た目が変わっても、記事で見せたい対象が灯台なら、その意味を一貫して保つ。画像の選択肢が増えたときこそ、説明の軸が必要になる。

2013年の草案が残した面白さは、新しいタグの綴り以上に役割の分担にある。ページは折りたためるようになった。その中の写真も、折りたたみながら主役を守れるようになった。ブラウザーが日常の選択を処理し、写真編集者が写真の意味を守る。灯台はようやくスマホの中でも建物に戻った。