響應式Web設計之初探圖像處理
注：這篇文章發(fā)布于September 27th, 2011，作者是 Jason Grigsby
在我上一篇的博文“什么是移動優(yōu)先的響應式Web設計”中，我提到了一個用來判別一個響應式Web設計是否是“移動優(yōu)先”的標準，即這個設計是否有處理IMG標簽的策略。
最近在國外關于一個Web設計的網(wǎng)站Smashing Magazine上的一篇文章總結了一些響應式Web設計技術，其中包括幾個處理IMG標簽的新的方法。因此，現(xiàn)在非常適宜深入挖掘一下這個問題以及可能的一些解決方法了。
為什么IMG標簽是響應式Web設計的關鍵
如果你想要你的站點盡可能快地加載，你會想要傳送比實際需要更大的文件。很多響應式Web設計給移動設備提供的圖像是適合于臺式機的，然后再讓移動設備去修改圖像大小。
在我的研究中，我發(fā)現(xiàn)幾乎傳送到移動設備上的圖像幾乎需要減掉文件大小的80%才與實際需要相符。
那么在響應式設計中，IMG元素有什么問題呢?不像CSS圖片可以通過媒體查詢語句為不同分辨率的屏幕提供不同的源文件，IMGs只有一個單獨的源屬性。
什么是響應式的圖像
響應式的圖像是使用HTML的IMG標簽傳送的圖片，這些圖片可以根據(jù)不同的屏幕大小而改變圖片來源?？梢杂泻芏嗉夹g方法來實現(xiàn)響應式的圖像設計。
就我所知，Scott Jehl第一個使用了響應式的圖像這個短語來描述圖像來源問題的javascript解決方案。他最近將響應式的圖像定義為一個通用的術語，因此，我希望他不會介意我拓展了他對這個短語的定義，以便來描述在響應式設計中用來解決提供合適大小圖像的問題的技術。
響應式的圖像問題面臨的挑戰(zhàn)
有一些挑戰(zhàn)是響應式的圖像技術所普遍面臨的。當我們來看已經(jīng)提出的各種解決方案的時候，我們需要將這些問題記在腦海中。
最低標準：直接下載移動設備適用圖像，無需多余下載
Scott Jehl為響應式圖像設計提出了一個最小標準：
◆ 直接就下載適用于移動設備的圖像
◆ 升級到大的圖像時無需下載兩個圖像
這兩個都是必須要達到的目標。
第一次下載頁面的問題
任何一個依賴于客戶端腳本來決定應該提供哪一個圖像源的解決方案都會遭遇第一次下載頁面的問題。當用戶第一次訪問一個站點的時候，服務器端并不知道應該提供多大的圖片。
來自于Bryan Rieger的 Muddling Through the Mobile Web 中的圖像, 由 wscullin攝影, 受 Creative Commons保護.
如果加入了可以加載合適大小圖片的javascript代碼，那么第一次下載頁面時相關信息就可以通過cookies以及類似技術從用戶端獲得。在理論上說，對于接下來的請求，服務器端都知道應該在IMG標簽中包含什么樣的圖像大小了。
第一次加載速度是非常重要的。一個用戶第一次體驗到的速度價格會決定他們對一個產(chǎn)品或者公司的印象。Google、Yahoo以及其他的一些公司都說過很小的速度差異就會對用戶使用產(chǎn)品造成很大區(qū)別。
競爭條件(Rendering Race Conditions)
依賴于使用javascript調整圖像來源屬性的技術需要確保調整發(fā)生在圖像請求開始之前。
瀏覽器開發(fā)者做了很多工作在來下載盡可能多的資源，這通常來說這是個好事。但是在響應式設計中，javascript代碼需要在任何圖像請求開始之前就解析出需要多大的圖像。
很多早期的工作都是通過使用動態(tài)庫標簽(dynamic base tags)來做的。這在javascript代碼是包含在head標簽中時是很有效的，但是當使用外部javascript文件時就難以避免要下載兩次圖像。
幾乎每一種客戶端技術都需要對不同瀏覽器處理以及下載資源的命令有非常深刻的理解。或者更實際一點說，任何一種方法都要經(jīng)過廣泛測試。
內(nèi)容分發(fā)網(wǎng)絡以及緩存
當你通過同一個url分發(fā)相同大小文件時，你會碰到一個由CDN以及其他網(wǎng)絡邊緣的緩存引起的問題。如果第一個人是在手機上請求一幅圖像，那么接下來的請求者就會看到在手機上顯示最優(yōu)的圖片，即使他們試用的是臺式機。如果想要避免這一點，就需要在策略中考慮CDNs。
未來友好的響應式圖像
如果我們相信“將來會有很多我們不曾想象多的互聯(lián)設備出現(xiàn)”，我們就需要考慮一下解決方案在未來友好的。除了現(xiàn)在所做的實驗之外，我們需要考慮一個可以長期使用的解決方案可能是什么樣子的。
比如說，很多早期的響應式圖像解決方案考慮了兩種圖像大小：一個用來提供給臺式機，一個用來提供給手機。但是，這兩種圖像大小能滿足正在到來的各種設備嗎?
另外，現(xiàn)在的很多解決方案只是解決了這個問題的某一個方面。他們可能通過客戶端的改變來改變圖像來源，但是，這卻給開發(fā)者留下了一個問題，即如何去處理圖像大小的改變。對于共享庫來說，限制范圍可以解決這個問題。
但是在我們考慮未來系統(tǒng)要怎樣才能成功時，我們需要考慮我們想要從服務器端和客戶端想要獲得什么。
下面是我認為一個能長期適用的技術需要考慮的一些事情：
◆ 支持絕對圖像大小的改變——我們不能預期到屏幕大小是多少。我們需要系統(tǒng)能自動處理圖像大小改變，并且能支持特定頁面的絕對大小改變
◆ 手工設計可以覆蓋自動的圖像大小改變——不是每一個圖像都可以不失去圖像含義而改變大小的。有時候對圖像進行裁剪比改變它的大小會有更好的效果。自動化的工具需要支持人工覆蓋。
◆ 需要支持高分辨率顯示——當面對iPhone4以及其他一些有高分辨率屏幕的時候我們應該采用什么方案呢?我們要給處于一個低端連接的高分辨率機器提供高像素的圖像嗎?這是一個開放性的問題。
但是不論我們現(xiàn)在選擇如何進行處理，很明確的一點就是屏幕分辨率會不斷增加的趨勢不會改變。至少，我們已經(jīng)看到在臺式機上會出現(xiàn)更高分辨率。
這意味著我們現(xiàn)在對大圖像的定義對將來的設備來說可能太小了。如果記住這一點，可能需要系統(tǒng)能接受最高分辯率的圖像——即使現(xiàn)在的設備并沒有這樣的分辨率——那么當新的有高分辨率的設備出現(xiàn)的時候，現(xiàn)有的技術才會適用。
◆ 連接速度應該是標準中應該考慮到的——如果我們能知道網(wǎng)絡連接的情況，我們就能更容易解決圖像大小問題了。我們需要一種更簡單的方式來獲得這個信息。
◆ IMG標簽可以被替換嗎?——所有的響應式圖像解決方案都在試圖處理現(xiàn)在的圖像標簽只有單一來源的問題。對于重新看待這個標簽，已經(jīng)有各種建議，看我們是否能找到一個長期的替換方案。
在Part 2中，我們將會對現(xiàn)有的響應式圖像設計方案進行更詳細的解析，看看哪一個是最有可能的。
原文：http://www.cloudfour.com/responsive-imgs/
譯文：http://www.webapptrend.com/2012/01/1351.html
【編輯推薦】
