不是因為web標準的初期，我已經看到了我們身邊一個看似很小的問題，社會反彈：響應圖像。
在過去的4年 （是的，它已經四年左右），我們在響應式設計看到的圖像的各種排列組合。 從設置的懶惰天max-width: 100%絕對最低你應該做的），更全功能的JavaScript實現，如Picturefill和Zurb的data-interchange方法，我們已經花了很多時間轉動輪子，撞我們的頭和尖叫在墻上。 我很高興地說，我們不懈的旅程即將結束。 在W3C和瀏覽器制造商得到了暗示。
響應圖像的狀態
在我們尋求神圣的右圖像服務給用戶夢寐以求的目標，我們對瀏覽器廠商到現在為止的態度在很大程度上是“忘記你 – 我們會做我們自己?！蔽耶斎灰膊焕?。 我們是如此細心的敏感圖像和暴露給所有的猜測和試驗通常不釋放我們得不耐煩（理應如此），并用JavaScript做了公眾的利益。
一個CSS過渡和一個負責任的圖像之間的差異，當然，他們是如何降解 。 如果一個CSS過渡不起作用，誰真正在乎呢？ 你的界面可能會有點神經質，但經驗作為一個整體不會真的受到影響，因為你的用戶仍然能夠完成他們的目標，消耗他們所需要的內容。
這真的是不帶有圖像的情況。 如何做一個新的形象標簽降解？ 在img標記了廣泛的認同，我什至無法找到時，W3C推薦它作為一個標準，比在一個小參考其他的HTML 4.01規范 。 更換或什至擴大在img標簽會像告訴弗蘭克·西納特拉戴棒球帽，而不是一個Fedora的-你會得到一些推回。
資源問題
作為響應式設計逐漸普及和通過它用戶消費信息的媒體變得無法控制，我們慢慢意識到， img本身是不會削減芥末。 我們開始問這樣的，“什么屏幕尺寸的用戶？”和“什么是屏幕的像素密度？”這些問題刺激我們的圖像技術，直到我們意識到，屏幕尺寸和像素密度都絕對給量沒有關系的問題可用帶寬來提供一個巨大的高清晰度圖像。
該解決方案得到了相當復雜的。 在通話picture元素開始，和一組名為響應圖像社區組（RICG）出現了。 該RICG開始工作的有關picture元素，與沿途的W3C共享工作。 其結果使我們今天所有的公司已經取得的進展的討論。
的介紹srcset
因為大多數敏感圖像社區在船上與picture元素期待著它的偉大polyfills，如Picturefill因為和，它說干就干，并且放出了深思熟慮和充實的文件，概述了一種叫srcset ，這是標準的一個擴展img標記。 是的，我知道 – 這感覺就像是從哪兒冒出來。 這也是超級復雜和過于限制通過限制你（暗示）的像素值，并使用microsyntax未允許的可擴展性，在未來的媒體查詢。 幸運的是，語法已發展成為我們所擁有的今天，這是一個相當強大的建議。
最近，安德魯·克拉克說，最好的時候，他啾啾 ，“看著響應圖像srcset和尺寸第一次屬性。 啊呀它是復雜的?！?/p>
我不能說這更好的自己。 讓我們來看看什么是我們正在處理：
<img alt="dog" src="dog.jpg" srcset="dog-HD.jpg 2x, dog-narrow.jpg 300w, dog-narrow-HD.jpg 600w 2x">
三大屬性在上面的代碼片段： alt ， src和srcset 。 的alt屬性是相同的，因為它一直是， src是回退，如果srcset不支持; 和srcset顯然是香餑餑這里。
我們可以看到三個參數srcset 。 首先是該圖像的路徑。 第二提供有關來源的自然寬度的瀏覽器信息，以便它知道要提供的資源給用戶（根據用戶的喜好和交叉引用與該sizes屬性 -我告訴你這是復雜的）。 最后一塊設置可選的像素比（ 2x在這個例子中指定了高清圖像）。
有一件事我真的很喜歡約srcset是，該規范指出，瀏覽器應包含一定的帶寬情況下的圖像分配偏好。 這意味著你不必擔心服2x的圖像的高清晰度屏幕，如果該設備是在眉頭3G連接。 用戶的喜好應該接管，并且瀏覽器會選擇適當的圖像服務。
準備picture元素
經過一番抱怨我們的新怪的朋友， srcset的RICG繼續工作的有關picture元素，它終于得到與瀏覽器廠商一些嚴重的牽引……嗯，就是用Chrome瀏覽器。 建議語法picture元素可能看起來很熟悉，因為我們看到它主要是在Picturefill的第一個版本，它是沒有什么不同怎么<audio>和<video>標記了。
<picture> <source media="(min-width: 600px)" srcset="large-1.jpg, large-2.jpg 2x"> <img alt="A fat dog" src="small-1.jpg"> </picture>
正如你所看到的， source標簽的picture元素，以及一個正常的img標記。 正如我們看到的src在srcset ，在img是一個備用的。 在source標簽，我們有什么看起來像一個媒體查詢，旁邊一個srcset包含像以前相同的圖像源和像素密度的參數屬性。 這似乎是一個很好的清潔方式普及響應圖像; 我們通常熟悉的語法，所以它應該很容易通過。
瀏覽器支持
該srcset屬性已經在Chrome中支持從版本34。在寫作的時候，它不支持任何其他地方。 Mozilla的似乎是工作的一個實現（手指交叉）。 Internet Explorer是遙遙無期。
的picture元素有更糟糕的支持; 它甚至沒有在Chrome呢。 但如Mozilla與srcset ，谷歌目前正致力于實現它。 如果你可以忍受通過規范讀書，我強烈推薦它。 雖然沒有太多的情節和人物的發展是相當弱，它仍然是一個相當不錯的讀取。
Picturefill 2.0的形成是因為原生的支持是相當接近 。 你知道我們需要一個堅如磐石的polyfill時要使用的時候正式問世，讓我們來看一看吧！
介紹Picturefill 2.0
Picturefill 2.0最近發布了測試版，這是從版本1相當大的跳躍。的RICG真正的目的是創建響應圖像的一站式解決方案 。 面臨的挑戰是創建一個腳本，可以讓你的開發人員，使用目前正在標準化的解決方案的任意組合，沒有它，腹脹到不使用它在所有會比較輕巧的地步。
試想polyfilling，通常會需要2秒使用需要10秒才能加載一個JavaScript文件來加載圖像 – 這將沒有多大意義。 Picturefill 2.0的規格非常密切關注（有一些故意疏失，我們就去了一個位），讓您使用避免了這種srcset或picture ，或兩者的組合。
雖然我們不能可靠地實現一切都在使用JavaScript（如合理的檢測帶寬，這將是一個用戶無論如何設置）的規格，我們當然可以照顧所有的，目的是要在HTML中的碎片（即元素和屬性）。 這個版本Picturefill的得到我們更接近了一步不需要Picturefill，這是誰曾經寫過polyfill人的終極目標。
如果您目前正在使用1.0版，我強烈建議升級到2.0。 這是朝著正確的圖像服務給用戶一個更好的解決方案邁出了一大步。 一些大的變化已作出的語法和功能。 讓我們來看看有什么新的。
有什么新的2.0
有一件事使這個polyfill不同于別人，我所看到的是它polyfills一個概念，而不是HTML的只是一個不支持的塊。 Picturefill 1.0使用跨度和自定義屬性來模仿我們怎么想的響應圖像應該工作。 根據記錄，這是一個很好的解決方案，而我目前使用它的很多我還沒有被轉換成2.0的項目。
在過去一年左右的時間，在規范srcset和picture已經成熟了那么多，所以我們現在可以真正得到使用的東西接近真實的語法。 Picturefill開始看起來像一個真正的polyfill，一是我們可以剝去時，真正的支持顯示了。
安裝和使用Polyfill
如果你已經讀到這里，那么你可能已經處理了過去的一些形式po??lyfill的。 這個人是沒有太大的不同。 Polyfills都應該是設置它和忘記它（從偷線龍科 ），但由于這是一個HTML polyfill，您將需要創建picture元素手動或使用某種形式的HTML下腳來為你做它。 幸運的是，HTML shivs是相當常見的，附帶的工具包，如Modernizr的 ; 只是確認picture中支持任何毒刃您選擇。
<!-- Create the actual picture element if you haven't already. --> <script> document.createElement( "picture" ); </script>
<!-- Asynchronously load the polyfill. --> <script src="picturefill.js" async></script>
除了 ??創建的picture元素，你只需要鏈接到腳本。 使用async屬性還建議，使Picturefill不加載擋住你的頁面。
使用Picturefill 2.0隨著srcset
讓我們來看看它提供了最好的支持和使用的語法srcset 。 它應該看起來很熟悉，因為它有我們看到討論規范時相同的屬性。
<img sizes="100vw, (min-width: 40em) 80vw" srcset="pic-small.png 400w, pic-medium.png 800w, pic-large.png 1200w" alt="Obama">
這個片段與規范之間最明顯的區別是沒有后備的src屬性，這是故意除去，以防止影像在不支持的瀏覽器下載兩次。 而且，說真的，這將是這點，如果圖像被下載了兩次？ 除此之外，這是很忠實的規范，但它可能會隨著時間的推移作為規范fleshes出來的polyfill成熟。
在sizes屬性告訴圖像大小的瀏覽器相對于視口。 這往往被忽視，因為srcset是流行語了，但這個屬性是非常重要的。 如果您想了解更多， 埃里克·波蒂斯使得很多的感覺這個“啊呀繁亂?！?/p>
使用Picturefill 2.0隨著picture元素
該RICG做這樣與Picturefill的第二個版本中做好的語法picture元素應該是毫不奇怪。 它的規格非常接近匹配：
<picture> <source srcset="extralarge.jpg, extralarge.jpg 2x" media="(min-width: 1000px)">
<source srcset="large.jpg, large.jpg 2x" media="(min-width: 800px)">
<source srcset="medium.jpg"> <img srcset="medium.jpg" alt="Cambodia Map"> </picture>
版本1.0和2.0之間的最大的變化是取消了一些傳統的HTML（div和跨度），并加入新的元素（的picture和source ）。 此外， srcset支持是內置的（哎呀，為什么不呢，對不對？這是在規范?。?。 這是偉大的進步為這個polyfill。
使用盡可能多或盡可能少的這些選項，只要你愿意。 符合規范的行，如果你不希望使用2x選項，你不必（依此類推）。 這與官方之間的差別picture元素是img的回退 。 你會注意到這里說的img后援也有srcset屬性，而不是一個正常的， src （這是廣泛支持的）。 再次，這是為了避免重復下載（這是一個真正的問題）。 該srcset在img標簽也將導致雙下載如果瀏覽器支持srcset但不是picture 。 這個錯誤應該得到的測試版本制定。
像許多好的polyfills，Picturefill 2.0可以通過編程方式暴露一個全局函數執行， picturefill() 這使您可以使用它在你想要的任何超髖JavaScript框架。 你可以閱讀有關的幾個選項，針對特定的圖像API文檔中 。
優雅地退化
在本文的前面，我提到降解的挑戰img擺好標簽不支持的瀏覽器。 這是在創造Picturefill 2.0另一個問題。 因為它是一個polyfill，不支持的瀏覽器的概念是不存在的（那種） – 我們使用JavaScript來迫使它的工作。
邊緣的情況是這樣的：如果瀏覽器本身不支持picture或srcset 并已關閉JavaScript，那么你會得到一個frowny臉。 我已經可以感覺到你的眼睛睜不開，但知道依靠它大規模之前，你的系統的局限性是很重要的。 如果用戶要遇到一個Picturefill’ed圖像中不支持的瀏覽器關閉JavaScript，他們會看到圖像的alt文本-一個可愛的小方法來加強對描述性的和有意義的重要性alt文本，是不是？
替代文字是回退，因為以前<noscript>解決造成問題，支持瀏覽器picture或srcset但已經禁用了JavaScript（兩個圖像會呈現）。 該小組還探討增加一個src屬性img （如說明書中），但是，結果在雙下載，這違背了相應的圖像資源分配給用戶的目的。
我們已經走過了漫長的道路與響應的圖像。 我們可以看到，光在隧道的盡頭，但很多工作仍然有許多工作要做。 我們期待您的幫助！
