指示性語法

<picture> 元素不會獨立轉譯任何內容,而是做為內部 <img> 元素的決策引擎。 告訴模型要轉譯的內容<picture> 接上 <audio><video> 元素已設定的先例:包裝函式元素 其中包含個別 <source> 元素。

<picture>
   
<source>
   
<source>
   
<img>
</picture>

此外,該內部 <img> 也可為舊版瀏覽器提供可靠的備用模式,以支援回應式圖片: 如果使用者的瀏覽器無法辨識 <picture> 元素,系統會予以忽略。然後也會捨棄 <source> 元素。 因為瀏覽器根本無法辨識這些代碼,或是沒有 <video><audio> 父項,因此也無法提供有意義的背景資訊。 不過,任何瀏覽器都能辨識內部 <img> 元素,而在其 src 中指定的來源也會正常轉譯。

「藝術指導」含有<picture>的圖片

根據網頁圖片大小變更圖片的內容或長寬比,通常稱為「藝術導向」 回應式圖片srcsetsizes 的設計可在使用者瀏覽器指示時,順暢地替換來源。 但有時候,就像調整網頁版面配置一樣,您應該在不同中斷點變更來源,以便更突顯內容。 舉例來說,如果全寬標頭圖片的中心點偏小,那麼在大型可視區域中的效果可能更好:

標題寬度的圖片,圖中的淺紫花環繞,周圍環繞著樹葉和莖,蜂巢造訪。

但是當圖片配合小型可視區域縮小時,圖片的中心焦點就可能遺失:

已縮小的淺紫藍色花朵標題寬度圖片。蜂蜜蜂幾乎看不到。

這些圖片來源的主題相同,但為了更明確地聚焦在所選主題上, 圖片來源在中斷點間變更的比例。舉例來說,將圖片中心放大一點 部分邊緣細節遭到裁切:

放大的淺紫藍色花朵。

這類「裁剪」但會讓使用者要求生成該圖像的所有資料 即使他們根本不見了

每個 source 元素都有用來定義所選 source 條件的屬性:media。這些屬性接受 媒體查詢和 type,可接受媒體類型 (之前稱為「MIME 類型」)。來源中的第一個 <source> 以與使用者目前的瀏覽情境進行比對,並根據該 source 上的 srcset 屬性內容 將會用於判斷該背景資訊適用的合適人選。在這個範例中,第一個包含 media 屬性的 source 必須符合使用者的可視區域大小才會由系統選取:

<picture>
 
<source media="(min-width: 1200px)" srcset="wide-crop.jpg">
 
<img src="close-crop.jpg" alt="…">
</picture>

如果 source 元素都不符合其 mediatype,請一律依順序指定內部 img 就會成為「預設」條件來源。如果您目前使用 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> 僅支援單一 widthheight 屬性,但省略這些屬性可能導致使用者體驗明顯不佳。 考量到「相對近期」,但 優質支援:除了 HTML 指定規格允許在 <source> 元素上使用 heightwidth 屬性。這些做法也能減少版面配置位移 就像在 <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> 元素之前,這是提供新圖片格式最可行的前端解決方案 瀏覽器會先要求並嘗試剖析圖片檔案,再判斷是否要捨棄圖片並載入備用內容。A 罩杯 常見的例子是指令碼:

   <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> 元素經過明確設計,可避免這些多餘的要求。雖然 Chrome 不支援 來識別不支援的格式,因此 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 中提供單一候選項目,因此會指示內部 <img> 以要求、轉移及算繪 pic.webp。任何「不支援」 WebP 的瀏覽器都會忽略 source, 沒有任何相反的指示,<img> 會比照 1992 年以來的成果,算繪 src 的內容。 當然,您不需要使用 type="image/jpeg" 指定第二個 <source> 元素,您可以假設為 JPEG 提供通用支援。

無論使用者的瀏覽環境為何,這項作業只需單一檔案傳輸即可完成,而且無須浪費頻寬 無法轉譯的圖片來源這正是前瞻性思維:未來將推出更多有效率的新型檔案格式 而 picture 不必使用 JavaScript,也不必使用伺服器端,因此我們就能運用這些類型 和 <img> 的所有速度

回應式圖片的未來

本文討論的所有標記模式在標準化方面都相當繁重: 正因如此,<img> 在網路世界中佔有一席之地,而且「<img>」的重大難題,而這些改變正是達成各種目標 這項運算難度較低如果您發現這些建議還有許多改善空間 標題標記模式,就完全正確。我們從一開始就制定這些標準,做為未來參考依據 做為建構基礎

這些解決方案都需要依賴標記,所以如同從伺服器的初始酬載中, 並及時要求瀏覽器要求圖片來源。這項限制導致 sizes 屬性不允許使用。

不過,由於這些功能是在網路平台中導入,因此導入了延遲圖片要求的原生方法。 系統不會要求含有 loading="lazy" 屬性的 <img> 元素,直到已知的頁面版面配置為止, 在使用者初始可視區域外的圖片要求,直到網頁轉譯程序的較晚期進行,可能可以避免 不必要的要求。瀏覽器充分瞭解提出要求時的網頁版面配置,因此 我們已在 HTML 規格中新增 sizes="auto" 屬性 避免在這些情況下刪除手動編寫的 sizes 屬性。

水平也提供 <picture> 元素,可配合部分令人驚豔的變更 以及設定網頁版面配置的樣式雖然可視區域資訊是大範圍版面配置決策的依據, 沒有辦法完全以元件層級的開發方法進行開發,也就是可以放進 網頁版面配置的任何部分,這些樣式都會根據元件本身所佔用的空間做出回應。這項問題帶來 到建立容器查詢:這是設定元素樣式的方法 自動調整資源配置

容器查詢語法只能穩定下來,瀏覽器支援相當有限。 在本文撰寫時,所新增的瀏覽器技術將為 <picture> 元素提供 產生相同作用的 container 屬性可能會允許根據 <source> 的選取條件 會讓 <picture> 元素的 <img> 佔用空間,而不是根據可視區域的大小。

如果聽起來有點含意, 因為還沒辦法使用。

回應式圖片標記能讓您長期下來輕鬆搭配運用,就像任何網路技術一樣, 服務、技術和架構,減輕了這類標記的負擔。在下一個單元中 並探討如何將所有學到的圖片格式、壓縮和回應式圖片整合至現代化的開發工作流程。