我相信應該不會有太多人反對，使用者閱讀網路與使用網路應用的方式，有很大一部分已經開始從桌面轉移到他們手上那小小的螢幕上了，不論是手機還是平版，或是手持遊戲機終端，網站、品牌的行動化對於企業、網站經營者與開發者而言，已經是個避不開，必須去學習、前進的方向，尤其是當他們發現網站的流量數據中，行動裝置的到達率漸漸的攀升到20%或更高時。

要在行動裝置上建立起與使用者的接觸點，在過去幾年，開發個原生APP是個主要方式，但是隨著愈來愈多行動作業系統的出現，如何最有效率的將品牌、產品、服務的內容傳遞給更多的使用者，使得跨平台開發成為一個顯著的需求。

對資源豐厚的公司、組織而言，針對多個主流行動平台開發原生行動應用或為一個可行的方式，但是有更多的公司是沒有這樣的預算與人力配置，更重要的是，根據Flurry的研究報告指出，使用者一天的APP使用時間中，平均會開啟的APP為7.9個，其中光是Facebook應用就佔去了18%，也因此，有愈來愈多的網站經營者採取了另一種行動化策略，那就是行動版網站。

在過去有很長一段時間，行動版網站以桌面版網站的另一個分身存在著，我們常常可以看見以”m”或者”mobile”、”touch”為開頭的網站URL，當使用者用手機進入網站時，不論是透過Server Side的UA偵測(例如使用WURFL或是使用Client-Side的Javascript進行UA偵測，一旦發現來源裝置為手持設備時，就將他從桌面版本的網站重導向到相對應的行動版本上，有些網站作得更細緻的話，還會區分手機版本與平板版本，但是很快的，網站管理者開始意識到這樣的多網站維護，對於網站資料的一致性、維護性上具有相當高的管理成本，於是，RWD(Responsive Web Design)的開發方法論逐漸受到重視。

RWD為Ethan Marcotte於2010年在A List Apart上發表的文章Responsive Web Design中提出來的一個網站設計方式，主要的設計思想是透過W3C Media Query去使用不同的CSS樣式表來調整、修飾網頁頁面的佈局與元素呈現方式，基本上就是One Theme to rule them(行動、桌面裝置) all，單一樣版，一致性的資料來源。

RWD一時間取代了Mobile Specific的方法論成為網站開發的主流，甚至在今年年初許多國外主流科技媒體不約而同的都將他列為2013主要的網路趨勢之一。但是，所有的方法論都會有他的優點與缺點，對RWD而言，他避免了多網站內容的維護的成本，最大可能性的保有了網站資料的一至性，但是在資源管理上，卻並不見得是最有效率的，回過頭來看，如果採用的是Mobile Specific的開發方式，開發者顯示網頁之前就可以知道資料所要投放的目標裝置類型，可以在伺服端就挑選好針對該裝置作過最適化設計的樣板與特製過後的相關資源，像是Javascript、CSS、圖片、影片等等，但是在RWD的設計方式下，瀏覽器必須在網頁下載完成之後才能決定頁面中元素、模組可使用空間，然後使用CSS去做相對應的縮放，像是max-width，如此一來在頻寬有限的行動裝置上也必須下載使用於桌面上的高畫質圖，對於良好的使用者的閱覽體驗影響甚鉅。

上述RWD在資源使用效率上的限制，在Apple提出Retia的高解析度螢幕後更顯嚴重，也因此開發者開始對有無更好的資源載入方式展開更積極的討論，也就是本系列文章的主題，Responsive Images，目前在標準制訂上有兩個主要的組織在進行，分別是WHATWG與RICG，而討論中的標準實作方式分為srcset與<picture>兩大方式，雖然在去年年底的時候將兩者合併的標準日漸成為可能性，但去瞭解為何會出現上述兩種不同的實作，開發者與標準制定實體間的衝突、爭論乃至於妥協，都有助於我們去瞭解為何一項開發標準的產生是如此的複雜縝密，我會在接下來的系列文章中與大家分享這一個過程

最後，相信大家都有些疑問，聽到目前為止，這似乎是CSS相關的技術呀？跟JS的關係是？？？

OK！其實就現階段而言，還沒有任何一個瀏覽器有對上面所提到的兩個W3C的實作標准進行支援，如果想要在現階段實作Responsive Image在專案上的話，必須透過一些JS的Polyfill，不論你是srcset還是<picture>的支持者，各自都有JS專案去讓你在過渡期中去進行準標準的實作，這會詳述在後續文章中

to be continue ...