無論您的學習程度為何,都不太需要介紹 <img>
元素。
1993 年時在 Netscape 推出 (「馬賽克」) 推出,並在 1995 年納入 HTML 規格中,<img>
向來在網路平台中扮演了簡單卻強大的角色。開發人員新增具有 src
屬性的「來源」圖片檔,並在圖片無法顯示或輔助技術要求替代圖片時,提供含有 alt
屬性的文字替代文字。接著,瀏覽器只會執行一項工作:取得並盡快呈現圖片資料。
就大部分網頁程式開發而言,處理圖片並不容易。儘管現代網路較為複雜,但處理圖片的基本原則並未改變:使用適合網路的圖片格式達成相容性、使用合理的壓縮功能來節省頻寬,以及適用於頁面版面配置中圖片空間的尺寸。
正如我們先前的做法,採用固定寬度的版面配置,我們才更認真地反映使用者如何體驗網路,因此讓整個過程變得複雜。設定圖片來源的大小特別容易。假設圖片佔據寬度為五百百像素,且高度為 300 像素,即為指定相同大小的來源圖片。
使用回應式版面配置的圖片
除了靈活的版面配置和使用 CSS 媒體查詢外,「彈性圖片和媒體」是回應式網頁設計的三大面向之一。為了提高圖片的彈性,開發人員開始使用 CSS 將 max-width: 100%
設定為圖片 (或整個網站的所有圖片),指示瀏覽器的轉譯引擎,避免圖片縮小到其父項容器。從視覺上來說,這個做法完美地將光柵圖片縮小,看起來流暢無比。如果使用 CSS 的一行或兩行,縮小後的圖片會一直看起來像我們已指定該大小要顯示的圖片來源。如果轉譯引擎收到的圖片資料超過版面配置中佔用的空間,轉譯引擎就能做出明智的決定,判斷如何算繪縮小的圖片,而且不會導入任何視覺構件或進行模糊處理。
通常不會想要「放大」圖片,也就是以大於來源圖片內建函式的尺寸轉譯 <img>
。顯示的圖片會模糊不清,且看起來有顆粒狀。
使用 img { max-width: 100% }
表示可以彈性調整容器大小,系統會視情況縮小圖片。不同於設定更嚴謹的 width: 100%
,這麼做也能確保圖片在縮放後不會超出其內建大小。長久以來,這已成為處理圖片的規則:使用瀏覽器能夠理解的格式、採用合理的壓縮程度,且圖片絕不會向上擴充。
但就像這樣的做法簡單又有效,結果導致成本高昂。由於 <img>
僅支援單一圖片來源,因此這個方法需要我們提供內建函式 (最大尺寸) 的圖片素材資源。如果圖片佔用了版面配置中空間介於 300px
到 2000px
之間的空間 (視使用者的可視區域大小而定),圖片來源必須採用內建寬度至少為 2000px
的圖片。如果使用者只透過小型可視區域查看網頁,則所有內容都會正常顯示,圖片的縮放比例也很不錯。在轉譯的頁面中,經過縮小但放大的來源圖片看起來不會與適當大小的圖片不同。不過,系統還是會在傳輸及算繪 2000px
寬幅圖片,透過大量頻寬和處理能力來燒錄,而不會帶來實質好處。
首款「Retina」的裝置問世,由於螢幕「密度」和可視區域大小一樣重要,因此情況顯得更加糟糕。圖片來源需要更大的內建寬度,才能配合高密度顯示。簡單來說,如果螢幕密度是雙倍,圖片像素就會盡可能銳利達兩倍。
在本例中,開發人員再次仰賴算繪引擎的視覺縮小圖片功能。透過在 src
中提供瀏覽器 800px
寬幅來源圖片,然後透過 CSS 指定應以 400px
寬顯示的圖片,結果圖片算繪為像素密度的兩倍:
當然,為了配合版面配置和高密度螢幕的最大可用空間,只有一張來源圖片能以「視覺化方式」的形式運作,供所有使用者使用。顯示在小型且低密度螢幕上的高解析度圖片來源,看起來會與其他小型的低密度圖片看起來一樣,但速度較慢。使用者仍會看到該大型 4000 像素寬圖片來源的所有效能成本,而不致於影響。
長久以來,<img>
大部分都執行了一項操作,那就是「圖片資料無法放到螢幕上」。結果大致上沒問題,但 <img>
並沒有趕上我們所遇到的瀏覽環境極端變動的任務。雖然回應式網頁設計是主流的開發實務,但瀏覽器在將近 20 年的img
效能方面最佳化了將近二十年的執行效能,但對大多數特權使用者來說,內容網頁的圖片一開始就沒有效率。無論瀏覽器要求、剖析及轉譯圖片來源的速度有多快,該素材資源的大小都可能會遠超過使用者需要的尺寸。