<picture> 要素は単独では何もレンダリングしませんが、代わりに内部 <img> 要素の決定エンジンとして機能します。
指示を出します。<picture> は、<audio> 要素と <video> 要素によってすでに設定されている前例（ラッパー要素）に従います。
（個々の <source> 要素を含む）
<picture>
<source …>
<source …>
<img …>
</picture …>
この内部 <img> は、レスポンシブ画像をサポートしていない古いブラウザ向けの信頼性の高いフォールバック パターンも提供します。
<picture> 要素がユーザーのブラウザで認識されない場合、無視されます。その後、<source> 要素も破棄されます。
これは、ブラウザはそれらをまったく認識しないか、<video> または <audio> の親がないと意味のあるコンテキストが得られないためです。
ただし、内部の <img> 要素はどのブラウザでも認識され、その src で指定されたソースは想定どおりにレンダリングされます。
「アート ディレクション」<picture> を含む画像
一般的に「アート ディレクション」とは、ページ内の画像のサイズに応じて画像の内容やアスペクト比を変更する行為を指します。
作成します。srcset と sizes は目に見えない形で動作し、ユーザーのブラウザの指示に応じてソースをシームレスに切り替えるように設計されています。
しかし、ページ レイアウトを調整するのと同じように、コンテンツが強調されるように、ブレークポイントをまたいでソースを変更したい場合もあります。
たとえば、次のように中央のフォーカスが小さい全幅のヘッダー画像は、大きなビューポートでは適切に表示される可能性があります。
ただし、小さいビューポートに合わせて縮小すると、画像の中心が失われてしまう可能性があります。
これらの画像ソースの被写体は同じですが、その被写体を視覚的に強調するには、 ブレークポイントを越えて変更するための画像ソースの比率。たとえば、画像の中心を拡大して、 トリミングした端のディテールの一部を次に示します。
こういう「切り抜き」はCSS で指定することもできますが、ユーザーはその画像を構成するすべてのデータをリクエストすることになります。 たとえ目にすることもないでしょう
各 source 要素には、その source の選択条件を定義する属性があります。media は、
メディアクエリ、メディアタイプ（以前の「MIME タイプ」）を受け入れる type があります。ソースの最初の <source>
ユーザーの現在のブラウジング コンテキストに一致する順序が選択され、その source の srcset 属性の内容が確認されます。
そのコンテキストに適した候補を決定します。この例では、media 属性を持つ最初の source は、
ユーザーのビューポートのサイズに一致するものが 1 つ選択されます。
<picture>
<source media="(min-width: 1200px)" srcset="wide-crop.jpg">
<img src="close-crop.jpg" alt="…">
</picture>
内側の img は常に順序の最後に指定する必要があります（どの source 要素が media または type とも一致しない場合）
その画像は「デフォルト」として機能し、あります。min-width 個のメディアクエリを使用する場合は、最大
前のコードのように、ソースから分離します。max-width メディアクエリを使用する場合は、最小のソースを最初に配置する必要があります。
<picture>
<source media="(max-width: 400px)" srcset="mid-bp.jpg">
<source media="(max-width: 800px)" srcset="high-bp.jpg">
<img src="highest-bp.jpg" alt="…">
</picture>
指定した条件に基づいてソースが選択されると、source の srcset 属性が
<img> 自体が定義されたように <img> を使用し、sizes を使用してアート向けの画像を最適化できる
あります。
<picture>
<source media="(min-width: 800px)" srcset="high-bp-1600.jpg 1600w, high-bp-1000.jpg 1000w">
<source srcset="lower-bp-1200.jpg 1200w, lower-bp-800.jpg 800w">
<img src="fallback.jpg" alt="…" sizes="calc(100vw - 2em)">
</picture>
選択した <source> 要素によってアスペクト比が異なる可能性がある場合は、もちろんパフォーマンス上の問題が発生します。
<img> がサポートしているのは 1 つの width 属性と height 属性のみですが、これらの属性を省略するとユーザー エクスペリエンスが大幅に低下する可能性があります。
このことを考慮すると、比較的最近のものですが、
十分にサポートされている - HTML への追加
仕様では、<source> 要素で height 属性と width 属性を使用できます。レイアウト シフトの低減にも
<img> と同様に、選択された <source> 要素に対して、レイアウト内で適切なスペースを予約します。
<picture>
<source
media="(min-width: 800px)"
srcset="high-bp-1600.jpg 1600w, high-bp-1000.jpg 1000w"
width="1600"
height="800">
<img src="fallback.jpg"
srcset="lower-bp-1200.jpg 1200w, lower-bp-800.jpg 800w"
sizes="calc(100vw - 2em)"
width="1200"
height="750"
alt="…">
</picture>
重要な点として、アート ディレクションはビューポートのサイズに基づく決定以外にも使用できます。
このようなケースの大半は、srcset/sizes を使用することでより効率的に処理できます。たとえば画像ソースを選択すると
ユーザーの好みのカラーパターンに合わせます。
<picture>
<source media="(prefers-color-scheme: dark)" srcset="hero-dark.jpg">
<img srcset="hero-light.jpg">
</picture>
type 属性
type 属性を使用すると、<picture> 要素の単一リクエスト決定エンジンを使用して画像形式のみを提供できます。
ブラウザに表示されます
画像形式と圧縮で説明したように、ブラウザで解析できないエンコードは、 作成します。
<picture> 要素の導入前は、新しい画像形式を配信する最も実行可能なフロントエンド ソリューションが必要でした。
ブラウザは画像ファイルをリクエストして解析を試行し、そのファイルを破棄してフォールバックを読み込むかどうかを判断します。
一般的な例は、次の行のスクリプトでした。
<img src="image.webp"
data-fallback="image.jpg"
onerror="this.src=this.getAttribute('data-fallback'); this.onerror=null;"
alt="...">
このパターンでは、image.webp のリクエストは引き続きすべてのブラウザで行われるため、ブラウザで無駄な転送をすることになります。
WebP はサポートしていませんWebP エンコードを解析できなかったブラウザは onerror イベントをスローし、スワップします。
data-fallback 値を src に変換します。無駄なソリューションだったが、やはりこのようなアプローチが唯一の選択肢だった
フロントエンドで使用できますブラウザは、カスタム スクリプトがカスタムスクリプトを実行する前に、画像のリクエストを
このプロセスをプリエンプトできませんでした。
<picture> 要素は、このような冗長なリクエストを回避するように明示的に設計されています。ブラウザがコンテナを
リクエストせずにサポートしていない形式を認識できるようにするため、type 属性はブラウザにソースについて警告します。
行うため、リクエストを実行するかどうかを決定できます。
type 属性では、メディアタイプ（旧 MIME タイプ）を指定します。
各 <source> の srcset 属性で指定された画像ソースの画像。これにより、ブラウザは取得されたすべての情報を
その source によって提供された画像候補が、外部コードなしでデコードできるかどうかを即座に判断する必要があります。
リクエストでは、メディアタイプが認識されない場合、<source> とそのすべての候補が無視され、ブラウザが処理を進めます。
<picture>
<source type="image/webp" srcset="pic.webp">
<img src="pic.jpg" alt="...">
</picture>
ここでは、WebP エンコードをサポートするブラウザは、type 属性で指定された image/webp メディアタイプを認識します。
<source> 要素の中でその要素を選択し、その要素を <source> 選択すると、srcset には候補が 1 つしかないため、内部に
<img> で pic.webp のリクエスト、転送、レンダリングを行います。WebP をサポートしていないブラウザでは、source が無視されます。
それに反する指示がない場合、<img> は 1992 年から行われてきたとおり、src のコンテンツをレンダリングします。
ここでは、2 つ目の <source> 要素を type="image/jpeg" で指定する必要はありません。もちろん、JPEG のユニバーサル サポートを想定できます。
ユーザーのブラウジングのコンテキストにかかわらず、これらすべてを 1 回のファイル転送で達成でき、帯域幅が無駄になることはありません。
画像ソースを検出できます。これは先進的な考えでもあります。より新しく効率的なファイル形式が登場するにつれて、
独自のメディアタイプと連携し、picture によりそれらのメディアタイプを活用できるようになります。JavaScript もサーバーサイドも不要です。
<img> のすべての速度をサポートしています。
レスポンシブ画像の未来
ここで取り上げたマークアップ パターンはすべて、標準化という点で大きな負担となります。つまり、
<img> のような確立されたウェブの中心的な存在は決して容易ではなく、そうした変化が目指す一連の問題も
多岐にわたりますこうした改善の余地はたくさんあると
マークアップパターンがあるならば、その通りです。これらの標準は当初から、将来に向けたベースラインとして
構築するためのテクノロジーです
これらのソリューションはすべてマークアップに依存しているので、サーバーからの最初のペイロードに含まれます。
ブラウザが画像ソースをリクエストするのに間に合いました。この制限により、sizes 属性が明らかに扱いづらくなっていました。
しかし、これらの機能がウェブ プラットフォームに導入されて以来、画像リクエストを遅延させるネイティブの方法が導入されました。
loading="lazy" 属性が指定された <img> 要素は、ページのレイアウトが判明するまではリクエストされません。
ページのレンダリング プロセスの後半まで、ユーザーの最初のビューポートの外にある画像のリクエストを
除外します。これらのリクエストが行われた時点でブラウザはページ レイアウトを完全に把握しているため、
sizes="auto" 属性は HTML 仕様への追加として提案されています
これにより、このようなケースで sizes 属性を手動で記述する手間を省くことができます。
今後予定されている <picture> 要素には、非常に画期的な変更がいくつか追加される予定です。
ページレイアウトのスタイルを設定しますビューポート情報はレイアウトに関する大まかな決定を行うための適切な基礎となりますが、
開発に対して完全なコンポーネント レベルのアプローチ、つまり、インフラストラクチャにドロップできるコンポーネントを
コンポーネント自体が占有するスペースに対応するスタイルで、ページ レイアウトのあらゆる部分に配置できます。この懸念は、
コンテナクエリの作成: 要素をスタイル設定する方法
ビューポートのみのサイズではなく、親コンテナのサイズに基づいて自動的に作成されます。
コンテナクエリの構文は安定化したばかりで、ブラウザのサポートは非常に限られていますが、
これを可能にするブラウザ技術を追加することで、<picture> 要素に
同じことを行えます。たとえば、container 属性を使用すると、属性に基づいて <source> 選択基準が
ビューポートのサイズではなく、<picture> 要素の <img> が占有するスペース。
ウェブの標準に関する議論は継続していますが、まだ解決には至っていません。それに見合うだけの理由があります。 まだ使用できません
レスポンシブな画像マークアップは、他のウェブ テクノロジーと同様に、時間の経過とともに使い勝手が良くなると約束していますが、 多くのサービス、テクノロジー、フレームワークを通じてこのマークアップを利用できます。次のモジュールでは 画像形式、圧縮、レスポンシブ画像について学んだことをすべて最新の開発ワークフローに統合する方法を見ていきます。