說到響應式設計，首先要提及的是其核心技術Media Queries。記得還是在我10年前上大學的時候，看著書本中描述響應式設計的愿景仿佛還如同昨日，如今隨著Media Queries受到瀏覽器廣泛支持而早已成為現實。我最早寫的關于Media Queries的CSS3 Media Queries 詳解一文，發布于2010-08-23，距今已然6年，并且Media Queries Lv3也已經在2012年成為W3C推薦標準——也正是2012年，算是響應式設計的爆發之年。

于是這些年來各種設計精巧的響應式頁面便層出不窮，雖然國內老牌網站鮮見(業務和瀏覽器的各種因素)，卻在國外遍地開花。雖然使用的算不上多，但這些年的一些思考需要整理一下，本文就是我近年來對響應式設計的實踐以及一些粗淺經驗和建議，分別從設計和代碼角度來看響應式頁面。

響應式設計

響應式設計(Responsive web design，以下皆簡稱RWD)致力于提供跨設備的好體驗。但說到底，RWD做的再好終究是無法同單一設備優化的頁面相比的，RWD的優點并非是體驗本身，而是基于一套代碼的適應性的體驗改良——從大多數意義上講，實際是指盡可能減少相同的頁面在移動端的縮放，平移和滾動。

因為覆蓋面更廣，RWD的設計里多出了許多額外需要權衡的取舍，這對設計和前端都有所要求，所以如果設計和前端是分開獨立運行，那么務必需要更為緊密的溝通。很多時候為了尋求設計和實現的平衡點，分工過于明確的團隊會額外消耗大量的溝通時間。

個人是贊同前端自己來設計RWD的，如果只一人操作RWD，那么還是加修設計的前端更合適一些，因為從設計出發常常妨礙RWD的初衷——設計的內容無法用一種結構來描述的話，RWD意義就不大了。如果是設計師主導設計頁面結構，那么一個簡單的原則，就是將內容切割分塊然后像堆積木一樣來倒序擺放。

適用范圍

RWD并非萬能，相反其適用面其實相當有限。廣義的RWD是需要自適應到手機屏幕的，對于4-6寸巴掌大小的屏幕，信息承載能力自然有限。雖然從PC端自適應的過程中可以做減法，但頁面核心內容還是被嚴格地限制著。所以復雜頁面不可能適合RWD——一個簡單的衡量標準是，頁面上需要表達的點一般不超過10個。實際上互聯網絕對多數的站點業務并不復雜，所以其實RWD還是很有市場，特別是對于展示類網站，RWD幾乎都是選。無奈國內小而美的戰點相對較少，所以RWD也就相對要少很多。

移動web設計

這幾年移動影響Web設計的趨勢已經越發明顯，簡單列舉一些常見的模式轉變：

滾動加載替代分頁，對應手機端的滑屏。 基于矢量的扁平化設計，高PPI屏幕清晰度和性能的需求 內容尺寸放大，開始以拇指觸碰的精度設計交互組件 縮減hover的使用，使得移動端和PC端交互一致 更為明顯的交互態，例如Button，受限于無法hover，那么人們必須第一眼就識別出交互組件的外觀 漢堡圖標和抽屜式頁面，這些都是APP的標準交互形式，現在已經不僅僅出現在移動端頁面里，甚至直接出現在PC端。

這些改變，使得我們漸漸一眼就能看出一個頁面是否是RWD——大尺寸交互元素配上簡單空曠的頁面風格。

RWD模式

既然移動影響了相當多的PC端設計，那么也一定有相當多的固有套路，比如：

通欄：總是最有效的突出內容且易于RWD控制的形式。 抽屜：多種類型屏幕里，彈窗的伸縮性往往受到更多限制。 折疊：屏幕的變換會使得定位元素的定位管理變得麻煩，當我們需要一個more info，往往不是彈窗不是定位浮層，而是向下展開更多內容。 自然換行：和下面要講的多語言更有關些。 多語言

RWD配上多語言，使得原本復雜的頁面更顯得麻煩。但是相比普通頁面，RWD和多語言的相性卻并不差。實際上寬松的頁面結構加上原本就為不同屏幕設計自適應布局，多語言化的話反而要更為順利一些，當然前提是設計之初就已經有了相當多的考慮。于是就會常常遇到“自然換行”，這種自然換行卻恰恰也是需要設計的一部分，一個頁面如果能保證大部分內容自然換行都不會影響頁面整體的話，才是成功的RWD。

響應式代碼

一般的認知是RWD因為一套結構的關系，所以比較節省開發資源。但實際節省下來的后端開發，與額外增加的前端工程以及設計上的制衡相互抵消。一個項目是否真的節省了資源最終還是要看項目本身的復雜度，不過從大的范圍來看，相對節約資源是正確的，當然付出的代價就是一種平庸，因為融合而又要做到體驗的極致是相當困難的。

Media Queries是RWD實現的基石，而寬度則又是RWD的核心維度（我們還是一如既往的不怎么關心高度～）。

設備

雖然我們常常為了某個設備制作RWD頁面，但真正的RWD頁面需要應對的并不是某某設備，而是頁面內容本身——針對內容做響應式設計，而不是針對某個設備。當然實際情況，大多數人還是會偏向對編寫針對設備斷點的代碼，比如下面這個是我以前為了一個團隊分享所畫的斷點圖示：

雖然已經是一年多以前的圖，但近幾年移動端變化已經減緩所以依舊可以看看。針對設備做優化的好處是直接有效，成本低可控制。如果當真對頁面內容做RWD，單一語言還比較好控制，多語言總是會遇到各種奇葩問題，可能在各種妥協下頁面的整體設計就一團糟了。

性能

就目前的流量和網絡來說，RWD還是顯得太笨重。之前我做過一些頁面的簡單對比，相同頁面平均速度要差3-4倍，相當可觀。分析原因主要還是因為PC的重量連帶給RWD后，拖慢了整體頁面的加載速度，無法與傳統的單一優化的H5頁面相比。這些問題等到未來網速加快會漸漸顯得不能刺眼，不過當前還不能忽視。

代碼特點

RWD的核心代碼關鍵詞是普通流（或稱常規流，normal flow）。普通流是最能保證自適應的CSS定位機制，清晰的文檔上下文秩序，在這個基礎上運用浮動和有限的定位，是RWD的主流做法。在這過程中有一些常見的編碼問題需要注意：

嚴格限制的position，z-index，overflow:hidden。雖然正常情況下這些CSS屬性也是需要一定限制的，但在RWD中顯得更為重要。 避免line-height垂直居中。由于無法確定在某種特定狀況下發生換行而使得頁面非常難看，除非能保證內容完全無折行可能，不然調整行高是毫無必要。 字體問題。傳統PC有一些奇技淫巧，比如字符箭頭，在RWD里容易出問題。曾經我們可能只需要考慮桌面環境（并且往往是windows為主），而現在需要面對的則是更為復雜的客戶端環境。使用的字符比以往更容易受到系統和設置的影響而出現錯位，應該盡力避免。 定寬的絕對定位。絕對定位常常用在寬度恒定的地方，比如icon。在多語言的情況下，如果能用定寬icon替代文本，那么應該優先考慮通用的圖形。這讓我想起來宜家家居的安裝說明書——如果你仔細看過他們的說明書的話，就會發現安裝說明只有圖示沒有任何文字出現。

值得一提的是，表格處理絕對是RWD的煩人問題之一。當需要把一張又長又寬的表格塞進手機里的時候，會發現真的非常無奈。目前對于這種情況往往有3種處理方式：

添加容器，并使得整個表格在容器中截斷，在移動端用滾動條查看。所有表格都能搞定，體驗蛋疼。 以display:table，display:table-cell等樣式模擬顯示PC端的表格，到移動端再將表格打散重新排布 。缺點是無法真正模擬復雜表格，對跨單元格的結構也無能為力，表格內容超長時也不如表格穩定，并且在移動端打散表格后常常會因為沒有th而使表格變得意義不明。

重慶網站建設

通過巧妙地隱藏和展示部分表格單元，讓表格在一定意義上變形為適合移動端的形式。這種方式通常只適合一些不太復雜的表格 兩個或更多表格做切換，不是真正意義上的RWD～這里只是列一下。 響應式與React

當前前端領域，React如火如荼，但React的響應式目前做起來就不那么方便。由于HTML由JS接管，反倒是出現了連結構也根據不同屏幕變化的做法，已經與傳統的響應式完全不同甚至是背道而馳的。

總結

響應式強迫性地精簡了頁面，是一場輕內容的戰斗。未來我們可能面臨更多未知的設備，響應式能否繼續發展取決于這些新設備適用度。就目前來說，RWD已經是非常成熟的一種套路，使用前只需確定業務是否合適即可。目前，無論是微軟，Google，Apple，他們的不少頁面都有相當不錯的體驗。

當前文章：【成都網站建設】響應式設計實踐手札
轉載注明：http://m.newbst.com/news/224907.html

成都網站建設公司_創新互聯，為您提供外貿建站、電子商務、企業網站制作、網站維護、網站策劃、品牌網站設計

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯