Responsive Web Design
響應式Web設計
ETHAN MARCOTTE原作 於2010年5月25日
http://alistapart.com/article/responsive-web-design
設計師熟知的在印刷媒體的控制功能，常常也會期望Web媒體會有，但是他們僅僅限制在打印出來的頁面上才能使用。我們必須接受這樣的事實：web根本沒有同樣的限制和為這樣的彈性准備的設計。但是首先我們必須接受這種落差和流程。
——John Allsopp, “A Dao of Web Design”
英國建築師Christopher Wren有一次開玩笑說他選擇了一個"以永恆為目標"的領域，而這樣的原則也有它吸引人的一面：不像是Web那種總讓人感覺是以下星期為目標的東西，建築是一個以他的持久性來定義的學科。一個建築的地基決定了它的底座，底座決定了他的結構，結構決定了它的外觀。建築的每一個階段都比上一個階段更固定，更難以改變。創造性的決定極其確切地決定了物理空間的形狀，規划好了人們幾十甚至幾百年間在這個范圍中活動的方式。
然而在Web上工作則是完全不同的事情。我們的工作內容由瞬時性定義，經常在一兩年里就要調整或者替換。不一致的窗口寬度，屏幕分辨率，用戶偏好以及我們用戶安裝的字體僅僅是在交付工作時要衡量的奇怪東西中的冰山一角。經年累月我們逐漸變得不可思議地精於此道。
但是形勢在變化，而且可能比我們想要的還快。移動瀏覽量預計三到五年內會超過桌面訪問。在三個具有支配地位的視頻游戲平台中就有兩個有Web瀏覽器（而且其中一個還非常棒。）。我們為了鼠標和鍵盤設計，為T9鍵盤設計，為手柄游戲控制器設計，也為觸屏設計。簡而言之，我們現在要面對比以往任何時候更大數量的設備、輸入方式以及瀏覽器種類。
近年來，我見到更多公司開始要求"iPhone版網站"作為他們項目的一部分。這是一個很有趣的說法：從表面來看，當然，這是說移動版WebKit完全達到瀏覽器的品質，同時也是跳出桌面思考的一個強有力的商業案例。但是作為設計師，我覺得我們經常從這樣明確的要求中尋找安慰，因為他們允許我們把面前的問題划分開來。我們可以把移動體驗明確地隔離到單獨的子域和空間中，跟"非iPhone版網站"分開。但是接下來呢？一個iPad網站？再來一個N90網站？我們真的能一直這樣保證為每一種新的用戶代理提供專門為之設計的體驗？從某種意義上講，這開始感覺像是一個零和游戲，但是我們——以及我們的設計——該如何適配呢？
彈性的基礎
讓我們考慮一個設計的例子。我創建了一個簡單的幻想雜志頁面。它是在流體格上的直接的兩欄布局，其中到處散布着一些彈性的圖片。作為非固定布局的長期支持者，我長期認為它們更加"面向未來"僅僅因為它們不針對特定布局。在某種程度上，規則是：彈性設計沒有對瀏覽器窗口寬度做任何假設，並且非常漂亮地適配了具有人像和景物圖模式的設備。
但是不論是固定設計還是流體設計，沒有任何設計可以在超出它最初考慮的環境時縮放自如，示例中的設計在瀏覽器窗口大小改變時完美地縮放，但在更低分辨率下關鍵點很快出現了，當用比800x600更小的視口去觀看時，logo后面的插圖被截斷了，導航文本則在不合適的地方換行，圖片和按鈕因為過於擁擠而失去易讀性。而不僅僅是分辨率過小時的造成的影響：當用寬屏去看這一設計時，圖片立刻變成了笨拙的尺寸，擠開了周圍的內容。
總的來說，我們的彈性設計桌面環境工作良好，因為它原本就是為之設計的，但是不能夠搞定差得太多的情況。
支持響應
最近，一個新興的學科名為"響應式結構設計"（譯者注：這是建築學領域的概念）開始設問物理空間到底能用於讓多少人通過它們。通過嵌入式機器人技術和伸縮性材料，建築師試驗使得藝術裝潢和牆體結構在收到擠壓時能夠彎曲、彈性和擴展。在裝滿人的時候，運動傳感器與氣候控制器配合以控制溫度和周圍光線。一些公司已經生產出了"智能玻璃技術",能夠在屋子里的居住人數量達到一定閾值的時候自動變得不透明，以給予他們一層額外的隱私保護。
在他們的書"響應式結構設計"中，Michael Fox 和 Miles Kemp描述這個更接近於"一個可以對話的多重循環系統；一個持續而有創造性的數據交換中心。"強調下我的看法，在我看來這是一個微妙但是強有力的區別：比起之前所說的固定的、不變的空間來規定特定的體驗，他們揭示了居住者和建築物之間可以，也應該動態地互相影響。
這就是我們要前進的道路。與其為每一種數目不斷增加的web設備裁切出一種毫無關聯的設計，我們可以將他們視為同一種體驗的不同面。我們可以為最佳視覺體驗來設計，但是在我們的設計中加入基於標准的技術是的它們不僅僅是彈性的，而且更好地適配到渲染它們的媒體上去。簡單地說，我們需要實踐響應式web設計。但是怎么做呢？
初識media query
在CSS2.1時代，我們的樣式表可以通過媒體類型來判斷設備。如果你有寫過打印用的樣式表，你應該非常熟悉這一概念：
<link rel="stylesheet" type="text/css" href="core.css"
media="screen" />
<link rel="stylesheet" type="text/css" href="print.css"
media="print" />
因為想要讓我們設計出來打印格式更好的頁面，CSS標准提供給我們一系列的可接受媒體類型，每一種都為特定的已知可以訪問web的設備定制。但是多數瀏覽器和設備從來沒有擁抱這一標准的精神，留下了大量實現不完整的媒體類型，或者根本就給忽略掉。
謝天謝地,W3C搞出來了media query作為CSS3標准的一部分，改進了媒體類型的承諾。media query允許我們不僅僅以特定設備類型為目標，還可以真正地檢查設備用來渲染我們作品的具體物理特征。例如，隨着移動WebKit的崛起，media query成為受歡迎的客戶端技術，可以為iPhone、Android手機和他們的親戚提供裁切講究的樣式表。要想做到這個，我們可以把一個查詢條件寫入外鏈樣式表的media屬性：
<link rel="stylesheet" type="text/css"
media="screen and (max-device-width: 480px)"
href="shetland.css" />
這個查詢條件包含兩部分：
- 一個媒體類型(screen), 以及
- 由圓括號括起來的真正查詢條件，包括要檢查的特定媒體特征(max-device-width)后跟目標值(480px)。
用通俗地話說，我們要求設備的水平分辨率(max-device-width)等於或者小於480px。如果這個檢測通過——也就是說，如果我們的作品在小屏幕設備如iPhone上面，設備就會加載sheland.css。否則，外鏈就會被完全忽略。
設計師們過去就曾經實踐過針對分辨率的布局，大部分都依賴像是Cameron Adams的nb腳本一樣的JS驅動的解決方案。但是media quey標准提供了一個媒體特性的宿主，它遠不止屏幕分辨率那么簡單，它極大地擴展了我們可以用查詢來檢測的范圍。還有就是，你可以在一次查詢中同時檢測多個屬性的值，只要使用and關鍵字鏈接起來就可以了：
<link rel="stylesheet" type="text/css"
media="screen and (max-device-width: 480px) and (resolution: 163dpi)"
href="shetland.css" />
還有更多，我們不僅僅可以在link標簽中引入media query。我們也可以把它們直接包含在CSS中作為@media規則的一部分。
@media screen and (max-device-width: 480px) {
.column {
float: none;
}
}
或者作為@import指令的一部分。
@import url("shetland.css") screen and (max-device-width: 480px);
然而在每一種情況下，作用是一樣的：如果設備通過了我們設置的media query檢測，相關的CSS就會作用到我們的標簽，簡單來說media query對於其它人來說就是條件注釋。並非針對特定版本的特定瀏覽器，我們可以以外科手術手法去糾正我們布局在縮放到並非原始和完美尺寸時出現的問題。
適配、響應與克服
現在我們轉過來看看頁面底部的圖片。在他們默認的布局中，有關的CSS看起來像是這樣：
.figure {
float: left;
margin: 0 3.317535545023696682% 1.5em 0; /* 21px / 633px */
width: 31.121642969984202211%; /* 197px / 633px */
}li#f-mycroft,
li#f-winter {
margin-right: 0;
}
我漏掉了幾個排版屬性而專注於布局：每個 .figure元素尺寸為包含它們那一列的大約三分之一，每一行的最后的圖片（li#f-mycroft, li#f-winter）右側的margin被清零。這個可以很好地解決問題，然而這可視區域一旦顯著地小於或者寬於我們原本的設計就不行了。用media query，我們根據特定分辨率做定點修復，適配我們的設計以應對顯示。
首先，在可視區域的分辨率降低到最低限600px的時候，讓我們來把頁面變成單欄。這樣在樣式表最底部，我們創建一個新的@media區塊，像是這樣：
@media screen and (max-width: 600px) {
.mast,
.intro,
.main,
.footer {
float: none;
width: auto;
}
}
如果你在一個現代桌面瀏覽器看我們更新后的頁面，然后把窗口尺寸減小到600px以下，media query將會關閉設計中主要元素的浮動，在文檔流中順次堆疊這些區塊。這樣我們的小型化設計就很好地做出來了，但是圖片還沒有很智能地縮小。如果我們引入另一個media query，我們可以相應地改變它們的布局：
@media screen and (max-width: 400px) {
.figure,
li#f-mycroft {
margin-right: 3.317535545023696682%; /* 21px / 633px */
width: 48.341232227488151658%; /* 306px / 633px */
} li#f-watson,
li#f-moriarty {
margin-right: 0;
}
}
不要在意這個很丑的百分比；我們只是重新計算了流體格的寬度來適應新的單欄布局。簡單地說，當可視區域的寬度下降到400px以下的時候，我們從三列的布局切換到二列的布局，讓這個圖片看上去更突出。
我們也可以給寬屏的顯示切實地做一些事情。針對高一些的分辨率，我們可以把圖片適配到六欄布局，把它們全都放在同一行：
@media screen and (min-width: 1300px) {
.figure,
li#f-mycroft {
margin-right: 3.317535545023696682%; /* 21px / 633px */
width: 13.902053712480252764%; /* 88px / 633px */
}
}
現在我們的圖片在分辨率譜系中的兩段都可以完美展現，可以根據窗口和設備分辨率自動優化它們的布局方式。
但是這只是個開始。通過我們嵌入在CSS中的media query，我們能改變的不僅僅是幾張新圖片的擺放：我們可以引入新的，可以更改的布局以搭配各種分辨率區段，可能使得導航在大屏幕視圖下更加突出，或者在小屏幕中重新定位到Logo上方。
而響應式設計並不僅僅是布局改變。media query允許我們實踐中改變自己的形態做到令人難以置信地高精確性適配頁面：我們可以在小屏幕上增加目標區域或者鏈接，在觸屏設備上更好地遵循費茨法則（譯注：Fitts's law）；有選擇地展現或者隱藏用於改善頁面導航元素。我們甚至可以實行響應式排版來更改文本的尺寸和框線，為提供顯示的設備優化閱讀體驗。
一些技術摘記
值得一提的是，media query的健壯性在現代瀏覽器中令人難以置信。桌面瀏覽器如Safari 3+, Chrome, Firefox 3.5+, 和Opera 7+ 都原生地支持media query, 更近一些的移動瀏覽器如Opera Mobile和移動WebKit也是如此. 當然了，這些桌面瀏覽器的舊版本不支持media query。而雖然微軟承諾在IE9中支持media query，但是Internet Explorer現在沒有原生實現（譯注：此文寫的時候IE9還沒出來，IE9和IE10確實已經完整支持了media query）。
盡管如此，假如你對於在遺老遺少級別的瀏覽器上實現media query，這里有JavaScript帶來的一線曙光：
- 有一個2007年的jQuery插件提供了不完全的media query，僅僅在加到不同的Link元素時提供了支持min-width和max-width兩個媒體屬性的支持.
- 更近一點的事情，css3-mediaqueries.js已經發布，這是一個承諾要在使用@media塊包含的時候“使得IE 5+, Firefox 1+ 以及Safari 2 對使用者透明地解析、檢測和應用CSS3 Media Query”的庫。在1.0版本發布的時候，我個人發現他很健壯，我計划要關注它的開發進程。
但是如果使用JavaScript無法引起你的興趣，這也是完全可以理解的。然而，這可以加強在彈性格的基礎上做布局的案例，確保你的設計在沒有media query的瀏覽器和設備上也利用了一些彈性設施。
前路展望
流體網格，彈性圖片以及media query是響應式web設計的三個技術要素，同時他要求一種新的思維方式。除了把我們的內容分成完全不同的、設備相關的體驗之外，我們可以使用media query來對我們的工作在不同的視覺上下文中做漸進增強。這不是說沒有適合將網站分成特定設備的商業案例；比如，如果用戶到你的移動站點來的想要找的東西比桌面內容更少，那么提供不同的內容就是最合適的做法。
但是這樣的設計思想不應該是我們的默認選項。現在比起以往任何時候，我們的設計工作都更傾向於不同梯度的體驗中展現。響應式web設計給我們提供了一個前進的道路，最終讓我們能夠做到"為事物的漲落而設計"。