該方法已經(jīng)在使用了，不過在使用方式上存在一些爭議。這些爭議主要來自兩方面：業(yè)界的web開發(fā)者和瀏覽器制造者。web開發(fā)者提議創(chuàng)建一個新的picture元素（類似HMTL5中的video這樣的元素），該元素中包含其他的圖片源，示例代碼如下：

其中的img元素是默認(rèn)情況下顯示的圖片源，在其上面的兩個source元素則是在特定媒體查詢（media queries）條件下顯示的圖片——這也是開發(fā)者所喜歡的一種解決方案。

Scott Jehl針對圖片元素創(chuàng)建了polyfill項目，就是利用了這種思想，你現(xiàn)在可是就可以使用它了。

瀏覽器開發(fā)者則是通過給img元素標(biāo)簽增加srcset屬性來解決此問題的，功能一樣，然而直覺上不好理解。

以srcset的一個值為例講解：

path-to-another-image.jpg 600w 200h 2x

path-to-another-image.jpg 是不言自明的，當(dāng)符合下述條件時就使用該 圖片

 依據(jù)media queries要求，設(shè)備最小尺寸為600w和200h

瀏覽器有以2x像素密度顯示的能力

因此這里所表達(dá)的意思是，當(dāng)瀏覽器能夠處理2x像素圖片，且設(shè)備至少是600px寬、200px高的情況下，使用此圖片源顯示。此種解決方法從瀏覽器開發(fā)者角度看是非常合適的，畢竟能夠讓瀏覽器自己通過算法獲取設(shè)備的兼容性和像素密度。

力圖小編在網(wǎng)上找到了提供響應(yīng)式圖片的做法，我們可以模仿它的做法，如下：

• Markup —默認(rèn)是用img元素標(biāo)簽
• javascript — 決定viewport的尺寸，將存儲在cookie中的相關(guān)信息傳給服務(wù)器，而后再改變img標(biāo)簽的src屬性。
• Server — 獲取初始圖片請求，讀取cookie，如果不是移動終端設(shè)備則返回1x1大小的空白占位圖。然后等待JS腳本將真正的圖片填充進去。

這種方式并沒有想期望中那樣完美，卻也給出了一種解決思路，可以讓其他人在上面繼續(xù)發(fā)揮。

許多后續(xù)的方法其思路與此相仿，默認(rèn)都是提供移動端圖片，繼而嘗試探測設(shè)備屬性后再發(fā)送合適大小的圖片。

Foresight.js是在給服務(wù)器發(fā)送請求之前用JavaScript去探測該設(shè)備是否支持高分辨率圖片，同時也探測該設(shè)備所在網(wǎng)絡(luò)的網(wǎng)速。依據(jù)探測結(jié)果才向服務(wù)器請求合適的圖片資源。

Images redux使用空白的1x1GIF（轉(zhuǎn)成base64格式）。它將該圖片設(shè)置為所有圖片的初始背景或占位符，提供更好的用戶體驗。由于圖片是依據(jù)CSS設(shè)置的，所以可用media queries改變響應(yīng)樣式。

HiSRC是一個jQuery插件，它能探測網(wǎng)絡(luò)速度與分辨率，默認(rèn)情況下只提供最小的圖片。但是HiSRC能夠探測設(shè)備更多的能力，然后提供更多不同類別的圖像。

總結(jié)

圖片響應(yīng)式化的第一步是讓它自適應(yīng)，移除高、寬屬性然后設(shè)置max-width屬性為100%。然而這并不能從根本上解決問題。主要的問題在于，那樣做會不得不創(chuàng)建一張大尺寸高分辨率的圖像，很明顯這種圖片并不利于移動終端設(shè)備的接收。

一種有效的解決方法是使用新的HTML語法，告知瀏覽器應(yīng)當(dāng)使用那張合適的圖片；也許我們應(yīng)當(dāng)創(chuàng)建新的圖像格式，那樣也能解決現(xiàn)在的問題。

不過為今之計，還是不得不借助現(xiàn)有的技術(shù)實現(xiàn)圖像響應(yīng)式。這些技術(shù)的思想是提供移動端版本的圖像，然后探測其是否還能處理更大的圖像，如果可以則使用Javascript腳本將更大的圖片替換默認(rèn)的小圖。

最后，青島網(wǎng)站設(shè)計的小編收集的響應(yīng)式圖片的解決方案，希望大家喜歡。